Embedded Accounting: Build vs Buy for Marketplaces
A scope list, a cost model with stated assumptions, and the conditions under which each answer is correct.
Every marketplace builds a ledger eventually. The only question is whether it is built deliberately, as a system with controls, or accidentally, as a balance column that three services write to and nobody quite trusts.
This article is about making that choice on purpose. It covers what the work actually contains, how to cost it without fooling yourself, and the specific conditions under which building is the right answer — because sometimes it is.
What "embedded accounting" means here
Embedded accounting means the books live inside your product rather than in an application someone opens separately. Your software records the entries as events happen, your users see whatever your interface shows them, and no one exports a spreadsheet to a bookkeeper at month end.
For a marketplace this covers, at minimum: buyer payments received, seller amounts owed, commission earned, payment-processing fees, VAT on your fees and on the underlying supply, refunds, chargebacks, reserves, payouts, and the reconciliation of all of it against a bank or payment provider.
What you are actually building if you build
The ledger itself is the small part. Teams consistently scope the first item and discover the rest afterwards.
| Component | What it involves |
|---|---|
| Journal and accounts | Balanced entries, chart of accounts, account types, opening balances |
| Immutability | Append-only storage, reversal and correction workflow, no in-place edits |
| Period control | Closing, locking, rejecting late postings, controlled reopening with an audit record |
| Idempotency | Keys, storage of prior responses, collision detection on changed payloads |
| Money handling | Exact decimal or minor-unit arithmetic, currency codes, FX rates and their source, rounding accounts |
| VAT engine | Per-country rates with validity dates, place of supply, reverse charge, deemed supplier rules, exemptions |
| VAT identification checks | Validation against the official registry, caching, timestamps, request identifiers, a manual review queue for failures |
| Documents | Invoices, credit notes, gapless numbering per series and year, PDF rendering, delivery |
| E-invoicing | Structured formats such as EN 16931 UBL, and per-country national formats where mandated |
| Bank ingestion | Statement import or a consented bank connection, deduplication of already-imported transactions |
| Reconciliation | Matching rules, scoring, partial matches, exceptions that a human can resolve |
| Payouts | Payment file generation, payout batching, matching payouts back to the underlying items |
| Reporting | Trial balance, balance sheet, profit and loss, cash flow, VAT summaries, aged debt |
| Tax registers and returns | Whatever your countries require, in the format the authority accepts |
| Audit | Actor, action, entity, and the change itself, queryable, for every mutation |
| Retention and export | Ten-year retention for OSS records, full data export, defensible archive |
Roughly two of those seventeen rows are the part most teams picture when they say "we'll build a ledger".
Costing it honestly
Any number here depends on your team, so treat the following as a method rather than a quote. Take the components above, assign each a size in engineer-weeks based on your own team's velocity, and then apply three corrections that estimates usually miss.
Correction one: the compliance components are not one-time. Rates change, thresholds change, formats change, and the EU's VAT in the Digital Age package brings dated obligations — OSS and IOSS changes from 1 January 2027, expanded platform rules from 1 July 2028, cross-border digital reporting from 1 July 2030. Build means you own each of those migrations.
Correction two: correctness work outlasts feature work. The first version handles the happy path. The long tail is refunds after payout, partial refunds, chargebacks arriving weeks later, currency rounding, duplicate webhooks, and settlement files that disagree with your records. This is where the calendar disappears.
Correction three: the accountant is a stakeholder, not a reviewer. Books that a finance professional will not sign off are not finished, and that feedback arrives late in a build.
A useful sanity check: price the smallest credible build — ledger, corrections, period locking, idempotency, money handling, one country's VAT, invoices, bank import, matching, and a basic report set — and compare it to a year of a metered service. Nordlet's published plans start at €10 per month with 3,000 requests included and run to €300 per month with 200,000 requests. If a build costs a fraction of a single engineer-year, that is a genuine argument for building. If it costs several engineer-years plus permanent maintenance, the comparison is not close, and it gets less close every year the rules change.
When building is genuinely right
Three cases, all real.
Your ledger is your product. If you are building a payments platform, a banking product, or a wallet where balance behaviour under concurrency is the differentiator, the ledger is core and should be yours. Consider ledger infrastructure products rather than a from-scratch build, and keep statutory accounting separate.
Your model does not fit any accounting system. Some marketplaces have genuinely unusual settlement structures — multi-party splits with conditional releases, escrow with staged milestones, complex reserve policies. If no product models it and the workarounds are worse than the build, build.
Your volume makes metered pricing wrong. At sufficiently extreme transaction rates, per-request pricing stops being attractive. Model it with real numbers before assuming it, because "extreme" here is higher than most platforms reach.
When buying is right
Buying wins when accounting is necessary but not differentiating, which is the common case. Nobody chooses your marketplace because your journal entries are elegant. They notice only when the books are wrong.
Buying is also the right call when your obligations are multi-country. Per-country VAT rules, evidence retention, and e-invoicing mandates are a permanent maintenance stream, and a vendor amortises that work across every customer. Nordlet ships per-country EU VAT with VIES validation, OSS and IOSS return computation, i.SAF registers, and EN 16931 UBL for Peppol as part of the product rather than as a project you schedule.
A middle path most teams end up on
The practical answer is usually not either. It is: buy the ledger, build the workflow.
The accounting backend owns the entries, the tax treatment, the documents, the period close, and the audit trail. Your product owns everything your users see and every business rule specific to your marketplace — when funds are released, what a reserve policy is, how disputes are handled, what the seller dashboard shows. You call the accounting API at the moments money is committed, and you keep the parts that are actually yours.
That boundary also survives change better than the alternatives. A new country adds configuration rather than a project. A new payout policy is your code, not a vendor request.
What to decide before you commit
- Is your ledger a differentiator or an obligation? Be honest; most are obligations.
- How many countries, and what does each require? Rates only, or returns, or registers, or submission.
- What is your correction story? Refunds after payout and late chargebacks are the cases that expose a weak design.
- Who signs the books? Involve that person before the design is settled, not after.
- What is the ten-year retention plan? OSS records must be kept for ten years from the end of the year of the transaction, and an archive is a system, not a backup.
- What does a migration look like in three years? In both directions. Build a test export on day one and keep it working.
FAQ
How long does it take to build a marketplace ledger?
A first version that posts balanced entries can be running in weeks. A version that handles refunds after payout, late chargebacks, multi-currency rounding, duplicate provider webhooks, period close, and an audit an accountant accepts takes substantially longer, and the maintenance never ends. Estimate the second one, because that is what production means.
Can we start with a balance column and migrate later?
You can, and many do, but plan for the migration to be harder than the original build. Reconstructing history from a mutable balance is only possible if you kept every event that changed it — which is to say, only if you already had a ledger.
Does an embedded accounting API replace our finance team?
No. It removes manual recording and reconciliation. Someone still closes the month, reviews exceptions, makes judgment calls, and files returns.
What about GDPR if the ledger is immutable?
Keep monetary facts and pseudonymous references in the immutable records, and personal details in a separate system with its own retention and deletion process. Immutability applies to the financial event, not to every attribute attached to it.
Is open-source accounting software a middle option?
It is a real option, and it changes the cost rather than removing it: you take on hosting, upgrades, per-country localisation, and compliance updates yourself. Price those before treating the licence saving as the whole picture.