PowerOffice books that agree in Odoo
The platform already holds the books
PowerOffice Go already keeps Norwegian accounts. Odoo does not replace it. Operations stay in Odoo: sales, stock, projects, time. PowerOffice is where finance posts and the auditor looks.
The work is to make those two ledgers the same books, without a monthly export ritual and without a spreadsheet holding the difference.
Masters move both ways: customers, vendors, products, employees, projects, departments. The chart of accounts comes from PowerOffice. Invoices and credit notes go out; status and customer-ledger payments come back. Vendor bills, timesheets, valuation and scrap journals go out. They do not come back.
You hold the PowerOffice subscription and the API credentials. We configure Odoo against them and hand them back.
- Platform
- PowerOffice Go, Norway
- Odoo side
- Partners, products, invoices, vendor bills, vouchers, payments, chart of accounts, COGS, employees, projects, timesheets, valuation
- Direction
- Two-way on masters and AR status. AP, timesheets, valuation: Odoo → PowerOffice. Payment state: PowerOffice → Odoo.
- Carried
- Odoo 14 through 19. One product, upgraded.
- Delivered for
- A Norwegian partner. End client under NDA.
- Availability
- Built to order. Not a module on the Apps Store.
Which field wins
The first customer that appears in both systems is the easy hour. Production is the week both sides edit the same record.
Both systems think they own the name. Someone fixes a customer in Odoo after PowerOffice already has it. The next import overwrites the fix. If nobody wrote down which side wins, finance finds it at month-end.
An invoice without an id is a second invoice. Export skips a document that already carries a PowerOffice id. Lose that link, or export before the id is stored, and the same bill posts twice.
A vendor bill that starts in PowerOffice is invisible here. AP export is one way. A cost entered only in PowerOffice does not appear on the Odoo bill. The two AP ledgers drift, and nobody is looking at the right one.
A failed line in a batch is easy to miss. The job continues. The error is a log row, not a blocked queue. If nobody opens the log, the floor kept invoicing and PowerOffice stopped.
Prerequisites fail first. No customer email, no product code, no mapped account: the invoice does not leave. That is not a PowerOffice outage. It is a master that was never ready.
Timesheets do not round-trip. Time goes to PowerOffice. It does not come back. Do not budget a two-way time ledger on this connector.
Payments arrive after the books were closed. Customer-ledger import creates Odoo payments against invoices that finance already thought were done. Month-end is when that becomes an argument.
Each of those has an answer below.
Write the field you own
Ownership in writing, before code. Which system may edit a customer name, a product account, an invoice number. The import is an overwrite of the matched record. We do not pretend it merges. If Odoo must keep a field, that field is not on the import.
A PowerOffice id is the skip key. If the id is already on the Odoo row, export does not create it again. A replay is not a second document.
Import is a job you choose to run. It is not a silent always-on merge. Chart, partners, products, employees, projects, invoice status: each has its own pass. Turn on the ones you mean.
Failures are a log you can open. Direction, operation, model, payload, company. A line that did not post is a row, not a server traceback that scrolled past.
Connection in settings, not in code. Per company. Test and production. We do not keep those credentials after handover.
Jobs on a schedule, and a button when you need one. It is a pull and a push on an interval, not a hope that PowerOffice will call us. How often is scoped to the site.
Invoice versus voucher is a setting. Some customers must leave as an outgoing invoice, some as a voucher. That is configured, not guessed at send time.
Mapping into Peppol is a different job, on the same Norwegian engagement, and lives on Banking & Finance. This page is the PowerOffice connector.
The whole ledger
Delivered for a Norwegian partner. End client unnamed. This is the Integration Engineering proof already on the hub: a two-way accounting sync that carries the whole ledger, not a slice of it. The deepest integration we have built, and it reconciles.
We have carried the same connector from Odoo 14 through 19. The objects grew (timesheets, voucher import, vendor-bill export, payment scheduling). The product was not rewritten each version.
Peppol on that engagement is the statutory send, not this module. Metering, Energy & Devices is the operations feed on related Nordic work. This page is PowerOffice Go.
- Delivered
- Two-way masters, AR export and status back, AP export, COGS, timesheets out, valuation, scheduled jobs, error log
- Carried
- Odoo 14 through 19
- Client
- Norwegian partner. End client unnamed.
- Also on that engagement
- Peppol (see Banking & Finance)
Credentials you hold
A PowerOffice Go subscription with API access, and a sandbox (or a test company) that is not production. We will not start against live books only.
A written map: which Odoo company, which PowerOffice organisation, which accounts, which invoice-versus-voucher rule. We will not guess a sales account.
A rule for the day both systems edit the same partner. Import overwrites. If that is unacceptable for a field, say so before go-live.
Someone who will export a real invoice, a credit note, a vendor bill, and a payment in sandbox the way they do in week three. Those are the payloads that break a sync built only on a test customer.
We do not resell PowerOffice, hold your keys after handover, or build against a screen-scrape of the portal.
Banking & Finance · Integration engineering · Odoo integration
Which field still drifts?
Send whether PowerOffice is the books, whether Odoo is operations, and which object keeps disagreeing. We can usually tell you in one reply whether that is a mapped two-way sync or a monthly export you should keep.