Guide · Balances
A running balance across unpaid invoices in Shopify
Shopify keeps track of every order a wholesale customer places: what it came to, what has been paid against it, and whether it is overdue. What it does not show is the number that customer's bookkeeper cares about: the balance of the whole account, moving as invoices are raised and payments come in. Merchants ask for this as "a running balance" — the column on a statement that goes up with every invoice and down with every payment.
This guide explains how that column is computed correctly, and the two places where a running balance usually goes wrong.
The arithmetic
A running balance is worked out one event at a time, in date order. Start with the balance carried forward from the last statement. For each event in the period: an invoice adds its amount; an edit or a return changes the order's value on the day it happened — up for items added, down for items taken off; a payment subtracts; a refund — money returned to the customer — adds back, because the return already took the items off the order. The last line of the activity table is the closing balance, and it must equal the sum of every open item's outstanding amount.
The two tables check each other: the activity table proves how the balance moved, the open-items table proves what it is made of. When both agree, the statement is right.
Carrying the balance forward
The opening balance of this period is the closing balance of the last statement you sent — the number the customer already has. Recomputing it from live data every month looks harmless until something arrives with a date last month's statement already covered — an order entered with an earlier date, say: the opening balance quietly changes, and the customer's bookkeeper, who filed last month's closing figure, can no longer reconcile.
The honest approach is to keep each statement exactly as it went out, carry its closing balance forward, and — when live history no longer reproduces that closing — show the difference as an explicit line dated the first day of the period, naming the order it relates to.
Partial payments and credits
An invoice paid in part stays an open item at its remainder, and ages on that remainder from its own due date. An overpayment is a negative open item — the customer is in credit on that order — and sits in the current bucket rather than aging. A company whose whole balance is negative should read "in credit" in words, never as a red number.
Doing it inside Shopify
StatementClerk keeps a ledger of every company order's money events, builds each statement by exactly that arithmetic and verifies the identities before anything is sent. Inside your Shopify admin, each company's page shows its running balance, and the dashboard lists each company with its balance, overdue amount and oldest open due date.
Questions
Why does a refund add to the balance?
Because the return is already on the statement as a line of its own: the refunded items come off the order's value on the day they came back. The cash refund is money that went back to the customer, so it adds back what that line took off. Treating the refund as a credit as well would count the return twice.
What if a company orders in two currencies?
Keep two running balances and send two statements. Converting between currencies on a balance document is a correctness risk for no benefit — the bookkeeper reconciles each currency ledger separately anyway.