How unpaid invoices arrive as Balance-Forward Invoices
One new Invoice per Client standing for what they owed before Pippin, itemized by original document and dated at the Migration Boundary.
Before you start
Stripe issues Invoices and Pippin’s books record them. That means an unpaid invoice from your old system cannot simply be copied in — the object the books post against does not exist until Stripe creates it.
So Pippin creates a new one. A Balance-Forward Invoice is a real, finalized, open Invoice standing for what a Client owed you on the day you moved, carrying one line per original document:
Invoice 1043 — 2026-11-15
Each line is that document’s remaining balance, not its face value. A partly-paid invoice arrives at what is left on it.
If this sounds familiar, it is what QuickBooks has always done: a customer opening balance there is not a balance at all, it is an invoice dated “as of”. Pippin itemizes it, so your Client can reconcile the figure against their own records.
Steps
- Open Settings › Import your books and choose the receivables import.
- Supply the export from your old system. Pippin needs, per row, the Client, the original number, the issue and due dates, and what is still owed.
- Rows are matched to Clients by exact email first, then by name where the file carries no email. A name that matches two Clients is refused rather than guessed.
- Review the preview. It lists every Invoice that will be created, each line on it, and every row refused with the reason.
- Post the batch.
Good to know
Your Clients are not emailed. Stripe’s notices are suppressed for the migration batch, and Stripe’s own dunning is turned off for these Invoices — they are already months into your collection process, and starting a second one on migration day helps nobody.
Tax is carried as a line, never recalculated. Recomputing it would price today’s rates against a sale made under last year’s, and the receivable would stop matching what the Client was actually billed.
A Client whose open items span more than one aging bucket gets one Invoice per bucket. Collapsing everything into a single Invoice would give Stripe one due date where there were several, and your A/R aging would read that one date — reporting a six-month-old debt as current. Splitting by bucket keeps each part where it belongs. A Client whose balance is entirely current, which is the usual case at a fiscal-year boundary, gets exactly one.
Ages are counted from the Migration Boundary, not from today, so the buckets describe the position your books were in when you moved.
Once created, these Invoices are ordinary Invoices. Payments allocate against them, partial payments work, and the aging report reads them like any other. The one visible seam is that your Stripe invoice numbers start fresh at the Boundary, so the numbers your Clients see will jump.