Platforms that add payments often already have billing. Subscriptions, invoices, usage charges, all running through some combination of a billing system and a processor. It works until the two stop agreeing with each other, and then a customer is double-charged, a failed payment goes uncollected for a month, and finance cannot tell which system is right.
Billing and payments are two layers of the same stack, and where they meet is where the money leaks. This is how they fit together, and the failure points that cost platforms real revenue. It is part of the last step of the embedded payments implementation roadmap, operating what you now own.
Billing decides what a customer owes and when. Payments executes the collection. They are separate layers: the billing system generates the charge, the payment stack moves the money, and the two must stay in sync on status, retries and reconciliation. Most recurring-revenue leakage comes not from pricing but from the seam between these two layers, where failed payments, retries and mismatched records quietly lose money.
How do billing and payments actually fit together?
Billing is the system of record for what is owed: the plan, the price, the schedule, the proration. Payments is the execution layer: authorization, capture, settlement. A charge starts in billing, gets executed in payments, and the result, success, decline or dispute, has to flow back to billing to keep the record true. When that loop is clean, revenue is recognized correctly. When it is not, the two systems drift and finance stops trusting either one. Reading the numbers straight starts with knowing how to read a payments P&L.
Why failed payments are a collections problem, not a billing problem
A meaningful share of recurring charges fail on the first attempt, most for recoverable reasons: an expired card, a temporary hold, an insufficient-funds moment. If your stack treats a failed charge as a closed event, that revenue is simply gone. If it treats it as the start of a recovery process, most of it comes back. This is dunning, and it is one of the highest-return, least-glamorous parts of the entire payments operation. The recovered dollars land straight in the payments line that drives how much a platform makes from payments.
Dunning and retries: the recovery layer
Dunning is the structured retry and outreach process that recovers failed payments: smart retry timing, card updater services and customer communication that prompts a fix without reading as a threat. The difference between naive retries (hammer the card daily) and intelligent dunning (retry when it is likely to work, update the card automatically, tell the customer clearly) is often several points of recovered revenue. On a subscription book, that is margin the platform keeps or loses based purely on the recovery layer. It sits right next to chargeback management and merchant activation as the operational work that decides whether a live program actually performs.
Reconciliation: keeping billing and payments honest
Reconciliation is the process that confirms what billing thinks happened matches what the payment stack and the bank actually did. Charges, refunds, fees, chargebacks and payouts all have to tie out. Skip it and small discrepancies compound into a number nobody trusts and an audit nobody enjoys. At platform scale, reconciliation is not a monthly spreadsheet, it is a continuous process, and it belongs in the implementation plan from day one.
Where platforms get it wrong
Bolting a processor onto a billing system and assuming they will stay in sync. Treating failed payments as final instead of recoverable. Running naive retries that get the card flagged. And deferring reconciliation until finance raises the alarm, by which point the drift is months deep. Every one of these is a revenue leak hiding as an operations detail.
Where billing and payments meet is where the money leaks. Most recurring-revenue loss is not a pricing problem, it is a seam problem, and the seam is fixable.
For help finding the leaks between your billing and payment layers before they compound, see the advisory engagement, or work the full sequence from the implementation roadmap.