A billing dashboard is easy until the money moves off-platform

A B2B billing dashboard demos beautifully. One screen pulls every invoice from the store, every charge from Stripe, every entry from the accounting tool, totals them, and marks the paid ones green. A finance owner looks at it and sees their whole month in one place. It looks finished.

It stays finished right up until the first payment that doesn't flow through Stripe — and in a B2B business, that payment arrives in week one. This piece is about that payment, because everything hard about this product is downstream of it, and almost nothing hard about it is the three API integrations the demo was built on.

The moment three records start disagreeing

Money in a real business moves through more than one door. A customer pays a large invoice by bank transfer, so the cash lands in the accounting system and Stripe never hears about it. A refund gets issued directly in the accounting tool. A Stripe charge succeeds but the store records the order a beat later, or a webhook is missed and it doesn't record at all. A credit note is applied by hand.

Each of those is ordinary, and each leaves the same wreckage: the same payment now exists — or fails to exist — in three systems that were updated by different people, at different times, through different doors. The store thinks the invoice is open. Stripe has no record of it. The ledger shows it paid. None of them is lying; each is simply right about its own slice and blind to the rest. The dashboard's actual job is not to display those three records side by side. It's to make them agree. That work has a name — reconciliation — and it is the product. The display is the part that demos; the reconciliation is the part someone pays monthly to keep.

Why reconciliation is the hard part, and it isn't the code

It would be comforting if this were a hard engineering problem, because engineering problems yield to effort. It isn't. Pulling the three feeds and lining up their rows is a week of ordinary work. The difficulty is that when the rows disagree, the truth is genuinely ambiguous, and resolving it is a judgment no API can make for you.

When Stripe says paid and the ledger says open, which one is right? Sometimes Stripe — a real card cleared and the bookkeeper hasn't caught up. Sometimes the ledger — the customer wired the money and Stripe was never involved. The dashboard cannot know which without a policy: a product decision about which source is authoritative for which kind of fact, how recent a record has to be to win, and — the part people skip — what a human does about the cases the policy can't settle on its own. That policy, plus the queue of exceptions a person works through by hand, is the difference between a screen that shows numbers and a product a finance team trusts. It's also the part a competitor can't clone by reading your API list, because it isn't in the APIs.

The first move is a record of your own

There's a structural prerequisite under all of this, and it's worth naming because it's the same move a smaller product already makes for a single payment source. To reconcile three records you need a fourth: one unified ledger of your own that the three external sources are reconciled against. Without it there's no place for "what we believe is true" to live, distinct from "what each provider currently says" — and reconciliation with no independent record to anchor on is just three opinions and no verdict.

That independent record is not a new idea here. CompanyGraph takes subscription payments through Stripe and keeps a local mirror of subscriptions and transactions — the webhook updates the mirror, and the product reads the mirror, never the provider live. That mirror is reconciliation's first move performed for one source: a record you own, to compare the provider against. The reasoning behind it is the whole of why a payment provider should never be your only record. A B2B dashboard is that same move widened from one source to three — and the local mirror that's merely prudent for a single subscription product becomes mandatory the instant a second source of truth exists to disagree with the first.

Everything else this product needs is the boring half a foundation already carries: the accounts, the admin screen where a human works the exception queue, the scheduled jobs that pull each source on a cadence, the log that records what was reconciled and when. So the build is weeks spent on the part that's genuinely hard — the policy and the ledger — rather than months also spent rebuilding the part that isn't. That speed holds only on the condition that the boring half exists already; from an empty repository, the reconciliation problem is the same size and the plumbing is added underneath it.

The verdict

This is a real SaaS, and a steady one — but the wedge is narrower than "finance teams," and naming it sharply is half the work. The customer who actually has this pain is the B2B business whose invoices get paid through more than one channel: card and bank transfer and the occasional cheque or off-platform credit, so the records genuinely diverge. A business where every payment runs through Stripe has no reconciliation problem and shouldn't buy this; the one taking money three ways has it every month and will. Aim at the second one. And the moat is the reconciliation logic, not the integrations. Anyone can pull invoices from a store, Stripe, and an accounting tool; that's exactly why it can't be the thing you sell. The product is the policy that decides truth when the three records disagree, and the human workflow that handles what the policy can't. Build that — the owned ledger, the resolution rules, the exception queue — and the three feeds are just inputs you plug in.

Which is also what makes the bet cheap to place when the foundation is already there. The honest question was never "can I read three billing APIs" — you can, in a week. It's whether you can get the reconciliation policy right for a real finance team before the edge cases pile up, and that's the part worth your whole attention. The accounts, admin, jobs, and logging that carry everything around it are meant to already exist, so that attention has somewhere to go.