Your numbers are only as good as what feeds them.

Sales from three platforms, payouts from two providers, payroll from a fourth system. We design how those flows land in Odoo — and we write the specification your integrator builds from. The history you bring with you is a different job — that one is migration.

What this usually looks like

Almost always the same story: the accounting is fine, and what arrives into it is not.

  • Sales come from more than one platform and land as a lump sum nobody can break down.
  • Payment provider payouts net fees, refunds and chargebacks into one line.
  • VAT is wrong on marketplace sales and nobody is sure why.
  • Payroll arrives from a separate system and is re-keyed every month.
  • Inventory value on the balance sheet has not been trusted in a year.
  • Your integrator asks what the accounting rule is, and nobody can answer.
  • Odoo does create the intercompany invoice — but it does not book the same way on both sides.

Why this one comes first

Every other practice depends on it. You cannot automate a flow that arrives malformed — automation just repeats the error faster. You cannot consolidate entities whose data does not share a structure. Fixing the inputs is unglamorous and it unblocks everything downstream.

  • 1reconciled source instead of a spreadsheet per platform
  • Rule-basedeach incoming flow books by a written rule, not by memory
  • Testableevery rule ships with the cases that prove it

How we do it

We design and specify. Your integrator builds. We confirm it books correctly — that division is the whole point.

  1. 1We map what arrivesEvery incoming flow: platforms, payment providers, payroll, expenses. What comes in, in what shape, at what frequency.
  2. 2We design the finance data modelChart of accounts, analytic structure, and above all what has to stay distinguishable at year-end. Most of the pain comes from decisions taken here by default.
  3. 3We write the accounting ruleFor each flow: what is booked, to which account, when, and how it reconciles. With the acceptance tests that prove it.
  4. 4Your integrator builds itThey develop the connector. We review the output against the tests and sign off that it books correctly.

What you receive

Something your integrator can build from without asking you a single accounting question.

  • The incoming flow mapEvery source, its format, its frequency, and where it currently breaks.
  • The finance data modelChart of accounts and analytic structure, with the reasoning behind each split.
  • The accounting specificationOne rule per flow, in the language a developer can implement and an auditor can check.
  • Acceptance testsThe cases that must pass before the connector is accepted. This is what stops a rebuild six months later.

If you came looking for one particular thing

The detail behind the practice, so you can check that your case is in it.

  • Payment service providers and third-party payment tools
  • Incoming flows from e-commerce platforms and marketplaces
  • Payroll flows and how they book
  • Inventory valuation and costing
  • ERP settings that affect the accounts
  • Incoming flows from providers and external systems

We don't just connect systems.

We make sure the financial information that comes out of them stays coherent.

  • The same sale books the same wayWhichever platform it came from, whatever the currency, whatever the return policy. One written rule, not a habit in somebody's head.
  • A refund reverses what the sale createdSame accounts, same analytic axes, same VAT treatment. Most connectors get the sale right and the refund wrong.
  • Every posted line ties back to its sourceLine by line, to the payout, the order, the payslip. What cannot be traced cannot be defended at year-end.

When this is not the answer

We specify, we do not build. That boundary is deliberate.

  • You want the connector developed. That is your integrator's work — we write what it must do, they make it do it.
  • You need a data warehouse or BI infrastructure beyond Odoo. That is specialist work and others do it better than we would.
  • Your flows are already clean and reconciled. Then the problem is elsewhere, and the free diagnostic will say so.

Common questions

No. We write the accounting rule and its acceptance tests; your integrator develops it. We then verify the output books correctly. This keeps us non-competing with the integrator and keeps the accounting responsibility with accountants.

The ones our clients actually use: Shopify, Amazon, WooCommerce, Magento for sales; Stripe, Mollie, Adyen, PayPal for payouts; the main payroll systems in each of our ten countries.

Usually easier. The flows are already arriving; the question is whether they book correctly. We test what exists before proposing to replace anything.

It is one of the reasons this practice exists. Marketplace sales carry different VAT treatment depending on the platform, the country and who is deemed supplier. It has to be encoded as a rule, not decided invoice by invoice.

Then that is the first deliverable. Restructuring it is disruptive once, and it is the single change that pays back on every close afterwards.

Often needed alongside

Start with your flows

The free diagnostic covers your incoming flows and shows you where they break.

Book the free diagnostic