Chapter 7 · Reading the ledger

This chapter answers one question: how do you reconstruct what actually happened to your money from balance transactions alone, and reconcile a full day by hand?

Every object in chapters 1 through 6 has an opinion about what happened. Balance transactions are not opinions. They are the double-entry record of every unit that entered or left each Stripe balance, and Stripe recommends them as "our recommended starting point for reporting on your account's balance activity" (docs.stripe.com/reports/balance-transaction-types).

Anatomy of a balance transaction

The source field is the join key for every audit in chapter 8: a balance transaction never floats free; it points at its cause.

The types that matter on a Connect platform

Definitions follow Stripe's balance-transaction-types page; the last two columns show direction from the platform account's point of view:

The shape detail that breaks spreadsheets

Chapter 1 promised this consequence. On a destination charge priced with application_fee_amount, the fee is withheld from the transfer rather than sent out and returned: the full charge lands on your balance, the charge less the fee moves on to the seller, and Stripe's processing fee comes out of your share (docs.stripe.com/connect/destination-charges). The platform ledger therefore reads: charge +120.00, stripe_fee −3.78, transfer −108.00. Nowhere in that day is a +12.00 credit. The platform's cut is the gap between the charge and the transfer, and a reader who goes hunting for a fee line concludes the fee was never collected.

The ApplicationFee object does exist, carrying amount 1200, and it is what refund_application_fee acts on later — it simply is not a movement. Priced instead with transfer_data[amount] of $108.00, the same sale writes the same two money lines, but no fee object exists at all and your cut is visible only in the export's Destination Platform Fee column. Identical cash, different evidence: one shape leaves something you can refund and audit, the other leaves you reconstructing it from order records. Filter your day by source objects, not by pattern assumptions.

A full day, reconciled by hand

One fabricated day on one fabricated destination-charge platform, priced with application_fee_amount, so each transfer is its sale less that sale's fee. Opening available balance: $400.00. Five sales ($120/$80/$50/$200/$90, each with a 10% fee), Stripe processing at 2.9% + 30¢, one full default refund, one 25% partial refund handled with both flags, one nightly payout of $150.00.

Verify the three checks a hand reconciliation always runs:

1. Category totals. Charges +540.00 − transfers 486.00 = +54.00, the day's withheld fees, appearing as a gap rather than as credits. Stripe fees −17.16 (3.78+2.62+1.75+6.10+2.91), refunds −170.00, reversal +45.00, fee return −5.00, payout −150.00. Sum: 54.00 − 17.16 − 170.00 + 45.00 − 5.00 − 150.00 = −243.16.
2. Balance identity. Opening 400.00 + net −243.16 = 156.84 closing — matches the running column exactly.
3. Payout support. At 18:00 the available balance was 306.84; the $150.00 payout is covered and leaves 156.84. A payout larger than the available (not pending) balance would be the first anomaly of the day.

Notice what the ledger shows that no dashboard summary did: the 15:03 refund cost $120.00 with no compensating line at all, while the 16:10 trio nets to −$10.00. Not −$5.00, either — the reversal reaches only the $180.00 that was actually transferred, so 25% of it is $45.00 against a $50.00 refund, and the $5.00 fee return lands on top of that. Same afternoon, opposite policies, visible only as line items.

[DIAGRAM: From event to ledger]
Left column: business events (Charge, Transfer, ApplicationFee,
Refund, Reversal, FeeReturn, Payout).
Middle: the objects they create (ch_, tr_, fee_, re_, trr_/via refund,
fr_, po_).
Right: the balance transactions each writes, with type labels.
Arrows one-to-many except reversals, annotated "one refund can write
zero, one, or three ledger lines depending on flags".
Caption: reconciliation is walking this diagram right to left.

What to check on your own platform

1. Export one recent day of balance transactions and reproduce this chapter's three checks by hand, once, before automating anything.
2. Group the day by type first, then by source — confirm every destination transfer equals its charge less the fee, and that an ApplicationFee object exists wherever you expect to be able to refund one.
3. Search the export for transfer_refund lines and match every one to the refund that motivated it; unmatched lines are findings.
4. Search for adjustment lines with dispute sources and confirm each appears in your disputes register.
5. Compare status: pending versus available totals at close of day; the gap is next week's payout, and miscounting it is the classic month-end surprise (chapter 9).

Sources: docs.stripe.com/reports/balance-transaction-types · docs.stripe.com/api/balance_transactions/object · docs.stripe.com/connect/destination-charges