Most fintechs run two separate stacks for the two sides of their payment economics. One system, or one spreadsheet, handles payables: what their providers charge them. Another handles billing: what they charge their own clients. It looks like sensible separation of concerns. It is actually the root of a problem, because both sides are derived from the same underlying transactions, and computing them on separate stacks guarantees the two will drift, disagree, and require reconciling against each other. That drift does not stay constant. It compounds. This is the case for running payables and billing off a single source of truth, and what it costs not to.
TL;DR
- Payables (what providers charge you) and billing (what you charge clients) are both derived from the same underlying transaction events.
- Run on separate stacks, they keep separate copies of that data, with separate definitions and contract versions, so they inevitably diverge.
- The inaccuracy compounds: you reconcile the two stacks against each other, you cannot trace an invoice to the provider transaction behind it, and your margin is an estimate built from two mismatched sources.
- A single source of truth makes both sides consistent by construction, traceable end to end, and able to show true per-transaction margin as a fact rather than an approximation.
- For a CFO, the payoff is a profit and loss you can trust, audit, and act on, instead of two numbers that never quite agree.
- This is an architecture choice rather than a feature: both pipelines reading from one canonical record of events.
Short answer
Payables and billing need the same source of truth because they are two computations on the same data: the transactions flowing through the business, priced against provider contracts on one side and client contracts on the other. When they run on separate systems, each keeps its own copy of the events, its own definitions, and its own view of which contract version applied, so the two diverge. That forces a third reconciliation between the stacks, breaks the lineage from a client invoice back to the provider transaction behind it, and turns margin into an estimate assembled from two mismatched sources. Running both off one canonical record of events makes them agree by construction, keeps every figure traceable, and makes per-transaction margin a fact rather than a guess.
The symmetry most fintechs miss
The two sides of payment economics look like different problems, which is why they usually get different tools. Payables is a cost-control problem: did our providers charge us correctly? Billing is a revenue problem: did we charge our clients correctly? Different teams often own them, and different software usually runs them.
But step back and they are the same shape. Both start from the same raw material, the transactions and period events flowing through the platform. Payables prices those events against provider contracts to determine cost. Billing prices the same events against client contracts to determine revenue. The inputs are identical; only the contracts differ. They are mirror images of one computation rather than two unrelated processes.
That symmetry is the whole point, and missing it is what leads teams to split the two onto separate stacks that then have no shared foundation.
What splitting them into separate stacks does
When payables and billing run on separate systems, each system needs the transaction data, so each ingests and stores its own copy. From that single fact, everything else follows.
Two copies of the data drift. The payables stack and the billing stack pull the events at different times, normalize them differently, and handle edge cases their own way. Before long they hold subtly different versions of what happened.
Two definitions diverge. What counts as a transaction, how an FX conversion is recorded, when a period closes: each stack answers these in its own terms, so even the same event is described differently on each side.
Two views of the contract. A contract amendment that should change both the cost and the price of an event may land in one stack and not the other, or on different dates, so the two sides rate the same activity under different terms.
None of this is exotic. It is the ordinary consequence of two systems holding two copies of the same data with no shared source. And it is the soil in which compounding inaccuracy grows.
Why the inaccuracy compounds
Separation does not produce a fixed, tolerable error. It produces an error that grows, for three reasons.
You reconcile the stacks against each other. Because the two sides disagree, someone has to reconcile payables against billing to make the books hang together, a third reconciliation on top of the two you already run. That reconciliation is itself manual, error-prone, and a place where discrepancies are quietly plugged rather than resolved.
You lose the lineage. With separate stacks, a line on a client invoice cannot be traced back to the provider transaction that underlies it, because the two live in different systems with different identifiers. That broken lineage is exactly the audit and diligence exposure that turns into findings when someone independent asks you to substantiate a number.
Your margin is an estimate, not a fact. Margin is revenue minus cost, but if revenue is computed in one stack and cost in another, on different data and different definitions, the margin you report is the difference between two approximations. Errors on each side do not cancel; they stack. An FX figure slightly wrong in payables and separately wrong in billing produces a margin that is wrong twice over, and you cannot see by how much, because there is no shared truth to check against.
Each period, on more volume and more contracts, those gaps widen. The inaccuracy compounds because the divergence compounds.
What one source of truth changes
The alternative is structural rather than cosmetic. Both pipelines read from a single canonical record of events, the same transactions and period assessments, captured once, in one form. Payables prices them against provider contracts; billing prices them against client contracts; both look at the same events.
Consistency by construction. The two sides cannot disagree about what happened, because they are reading the same record. The third reconciliation between stacks disappears, because there are no longer two stacks to reconcile.
Lineage end to end. Every client invoice line traces back through the events that produced it to the underlying provider transaction. The substantiation an auditor or investor wants is built in rather than reconstructed.
Margin as a fact. Because cost and revenue are computed from the same events, true per-transaction margin is visible directly rather than estimated. You can see, for any transaction, what it cost you and what you charged for it, and therefore what you actually made.
This is the idea behind running both sides of the profit and loss on one engine: the Billing P&L is simply revenue from the billing side minus cost from the payables side, off the same stream. It is only trustworthy because both numbers come from the same place.
Why this is an architecture decision, not a feature
The reason this cannot be bolted on later is that it is a decision about where the truth lives. Two stacks with two copies of the data cannot be made consistent by adding a feature; the inconsistency is structural. Making both sides agree requires them to share a foundation, a single canonical event ledger that both pipelines read from. That is an architectural choice made at the base of the system, which is why platforms built for this, such as Bluefyn, start from one record of events and derive both payables and billing from it, rather than stitching two separate products together after the fact. The single source of truth is not a capability on a checklist. It is the thing everything else either inherits or fails to.
The bottom line
Payables and billing are not two problems that happen to be related. They are one computation on the same transactions, run against two sets of contracts. Splitting them onto separate stacks gives each its own copy of the data, its own definitions, and its own view of the contracts, which guarantees they drift, forces a third reconciliation between them, breaks the lineage from invoice to transaction, and turns margin into the difference between two estimates. Those errors compound with every period of growth. Running both off a single source of truth removes the divergence at its root, makes both sides consistent and traceable, and turns the profit and loss from a number you hope is right into one you can prove. For a finance leader, that is the difference between reporting margin and knowing it.
Frequently asked questions
Why should payables and billing share a source of truth?
Because both are derived from the same transactions, priced against provider contracts on the payables side and client contracts on the billing side. Running them on separate systems means each keeps its own copy of the data, which drifts, so the two sides disagree and have to be reconciled against each other. One source of truth makes them consistent by construction.
What goes wrong when payables and billing run on separate stacks?
The two systems hold separate, diverging copies of the transaction data and apply contract versions independently, so they disagree. That forces an extra reconciliation between the stacks, breaks the ability to trace an invoice back to the underlying provider transaction, and makes reported margin the difference between two mismatched estimates.
How does splitting them create compounding inaccuracy?
The error is not fixed. Divergence between the two copies grows over time and volume, the inter-stack reconciliation introduces its own errors, and mistakes on each side stack rather than cancel, so margin can be wrong twice over. Each period of growth widens the gaps.
What is the benefit of one source of truth for margin?
Because cost and revenue are computed from the same events, true per-transaction margin becomes directly visible rather than estimated. You can see, for any transaction, what it cost and what you charged, and therefore what you actually earned, with the figures traceable back to the source.
Is a single source of truth a feature you can add later?
Not really. It is an architectural decision about where the truth lives. Two stacks with two copies of the data cannot be made consistent by adding a feature; consistency requires both pipelines to read from one canonical record of events, which is a choice made at the base of the system.
How does this relate to audit and diligence?
A single source of truth preserves lineage from a client invoice back to the provider transaction behind it, which is exactly the substantiation auditors and investors ask for. Separate stacks break that lineage, which is a common source of audit findings and diligence friction.
