# Recurring Billing Reconciliation for Subscriptions

- Author: PreciseBankFlow (https://precisebankflow.com)
- Published: 2026-10-17
- Category: Payment and deposit reconciliations
- Canonical: https://precisebankflow.com/blog/recurring-billing-reconciliation

> Recurring billing reconciliation for subscriptions: billing system to processor to bank, failed payments, retries, refunds and the revenue ledger.
Recurring billing reconciliation proves that every subscription invoice the billing system issued was charged once, that failed and retried charges are accounted for, and that the money collected reached the bank and the revenue ledger. It compares four records: billing invoices, processor charges, bank payouts and the ledger. Most gaps turn out to be retries, refunds or timing.

## What does recurring billing reconciliation compare?

Recurring billing reconciliation compares four records that each describe the same subscriptions. The billing system says who should have been charged and how much. The processor says which charges succeeded, failed, were refunded or disputed. The bank says which payouts arrived. The ledger says what was recorded as revenue, receivable and deferred revenue.

A subscription business can be wrong in any of those links while the others look fine. The billing system can issue an invoice that never reaches the processor. The processor can charge successfully but pay out into a reserve. The ledger can book revenue from invoices even though a tenth of them were never collected. Checking only bank to ledger misses all of that.

### Why subscriptions make this harder than one-off sales

- **Volume**: hundreds or thousands of small, identical charges on the same days.
- **Retries**: one invoice can produce several charge attempts, only one of which succeeds.
- **Mid-cycle changes**: upgrades, downgrades and cancellations create prorated credits.
- **Prepaid plans**: an annual plan collects twelve months of cash in one charge.

The work is the same each month, so it pays to build it as a fixed routine with the same reports in the same order.

## Subscription invoices in the billing system against processor charges

The first tie-out matches each subscription invoice to the processor charge that paid it. Every invoice should have exactly one successful charge, or be listed as unpaid. An invoice with two successful charges is a double charge. A successful charge with no invoice usually means a manual charge someone made outside the billing system.

Most processors that run subscriptions put the link in their reports. Stripe's [itemized payout reconciliation report](https://docs.stripe.com/reports/payout-reconciliation), for example, lists optional invoice and subscription ID columns for charges, refunds and disputes made through its billing product. With those columns, the match is a lookup: invoice ID in the billing export against invoice ID in the processor export.

### The four outcomes

| Billing invoice | Processor charge | Meaning |
| --- | --- | --- |
| Issued | One success | Collected, the normal case |
| Issued | Failures only | Unpaid, in retry or past due |
| Issued | Two successes | Double charge, refund one |
| None | Success | Charge outside billing, find the approval |

Run this match on invoice counts as well as amounts. A total that agrees can still hide one double charge offset by one missing charge of the same plan price.

## Failed subscription payments and retries

Failed subscription payments are charges the card issuer or bank declined. Billing systems usually retry them on a schedule, so one invoice can show several failed attempts before a success or a final failure. For the reconciliation, only the outcome matters: collected, still being retried, or given up. Each attempt is evidence, not a separate receivable.

Retry rules vary by system. Stripe's guide to [automatic payment retries in Stripe Billing](https://docs.stripe.com/billing/revenue-recovery/smart-retries) describes a recommended default of eight tries within two weeks for its Smart Retries setting, and lets the business choose what happens when retries run out: cancel the subscription, mark it unpaid, leave it past due or pause it. That setting decides how the unpaid invoice should sit in your books at month-end.

### How each state is booked

- **Recovered in the same month**: treat it as collected; no entry beyond the normal sale.
- **Still in retry at month-end**: the invoice is a receivable, and revenue for the period is earned if service was given.
- **Retries exhausted, subscription cancelled**: write off or void the invoice under your policy, and stop recognizing revenue for the next period.
- **Marked unpaid but service continued**: decide, as a policy, whether that period's revenue is collectable at all.

A month-end list of invoices in retry, with amounts and attempt counts, is the receivable detail for subscriptions. It should foot to the subscription receivable in the ledger.

## Subscription refunds, credits and proration

Subscription refunds, credits and proration are the mid-cycle changes that make billed amounts differ from plan prices. A refund returns money through the processor. A credit reduces a future invoice without moving money. Proration charges or credits the difference when a customer changes plan partway through a period. Each leaves a different trail.

Trace them separately:

- **Refunds** appear in the processor report and reduce a payout. Match each to a refund record in the billing system and to an approval.
- **Credits** appear only in the billing system. They lower the next invoice, so the charge is smaller, but no refund line exists.
- **Proration** appears as extra line items on an invoice. The invoice total still matches its charge; the plan price does not.

The common confusion is treating a credit as a missing payment, because the charge is less than the plan price. Read the invoice lines before calling anything short. For refunds made outside the processor, such as a check to a customer whose card expired, [reconciling customer refunds to the bank](/blog/reconcile-customer-refunds) covers how to evidence and match them.

## Subscription payouts from the processor to the bank

Subscription payouts carry the net of many charges, refunds, disputes and fees into the bank in one credit. The tie-out here is the same as for any processor: the sum of the net amounts in each payout's itemized report should equal one bank deposit. Subscription businesses add one complication, which is processor reserves.

A processor may hold part of a subscription merchant's balance for a period, especially when many customers prepay annual plans. Held funds reduce payouts but are still the business's money, so they belong in an asset account, not in fees. [Payment processor reserve accounting and release](/blog/payment-processor-reserve-accounting) explains how to book the hold and track each release.

At month-end, list any payout the processor sent that the bank has not posted. It is a timing item and should clear in the first days of the next month.

## The subscription revenue ledger: billed, collected and deferred

The subscription revenue ledger turns billing into accounting. Billed amounts for service given in the month are revenue. Billed amounts not yet collected are receivables. Amounts collected for service in later months, such as the unused part of an annual plan, are deferred revenue. The reconciliation proves each of those balances from the records above.

### Monthly checks on the ledger

1. Revenue for the month equals billed amounts for service in the month, less credits, plus the earned part of prepaid plans.
2. The subscription receivable equals the list of invoices in retry or past due.
3. Deferred revenue equals the unused months on prepaid plans, from a schedule by customer.
4. Processor clearing equals funds at the processor plus payouts in transit and any reserve held.

If the business books revenue straight from bank deposits, every one of these checks fails at once: revenue follows cash, prepaid plans are recognized up front, and receivables vanish. Rebuilding from invoices is the fix.

## Worked example: one month of recurring billing tied out

The example below is invented. A software company bills 400 monthly subscriptions at 49.00 on the first of the month, all by card. All figures are illustrative.

### Billing to processor

| Line (example) | Count | Amount |
| --- | --- | --- |
| Invoices issued | 400 | 19,600.00 |
| Charged on first attempt | 388 | 19,012.00 |
| Recovered on retry during the month | 9 | 441.00 |
| Still in retry at month-end | 3 | 147.00 |
| Successful charges | 397 | 19,453.00 |

Successful charges plus invoices still in retry equal invoices issued: 19,453.00 plus 147.00 is 19,600.00. Every invoice is accounted for.

### Processor to bank

| Line (example) | Amount |
| --- | --- |
| Successful charges | 19,453.00 |
| Less refunds (two customers) | -98.00 |
| Less processing fees | -586.40 |
| Net paid out for the month's activity | 18,768.60 |
| Payouts posted by the bank in the month | 17,912.30 |
| Payout sent on the last day, posted next month | 856.30 |

The posted payouts plus the one in transit equal the net: 17,912.30 plus 856.30 is 18,768.60. The ledger entries follow: 19,600.00 of revenue for service given, 98.00 of refunds, 586.40 of fees, a 147.00 receivable for the three invoices in retry, and 856.30 still in processor clearing as an in-transit payout.

## Which recurring billing differences should worry you?

The recurring billing differences that should worry you are the ones that do not shrink. Timing items, such as a payout in transit or an invoice in retry, clear within days or weeks. A growing count of uncharged invoices, charges without invoices, or a clearing account that drifts upward points to lost or invented money.

### Warning signs to look for

- The same customer appears twice in the successful charges for one invoice period.
- Charges with no billing invoice keep appearing from one staff user.
- Invoices in retry stay open after the retry window has closed.
- Deferred revenue does not fall when prepaid plans are used up.
- The bank deposits for subscriptions run below net payouts with no in-transit list to explain it.

Whatever method you use to reconcile the bank itself, the bank balance has to tie first. [Bank reconciliation methods compared](/blog/bank-reconciliation-methods) explains why proving both sides to an adjusted balance catches errors a one-sided check can miss.

PreciseBankFlow handles the bank leg: it foots each statement and matches statement lines to your ledger or register, listing payouts that never posted and deposits that match nothing. The billing and processor legs stay in your own reports. [Get started](/get-started) to see it on a month of your statements.