QuickBooks Customer Statements for Stripe Invoices

A customer owes you for four invoices across three months. Stripe raised all four, emailed all four, and retried the card on two of them. What Stripe has never sent that customer is a single document saying "here is everything you owe us, and here is the total."

That document exists. It lives in QuickBooks, it is called a statement, and for a business whose invoices originate in Stripe it is the point where QuickBooks stops being a passive destination for synced records and starts doing work Stripe does not do at all.

This post covers what a statement is, which of the three types to send, and the specific ways a statement built on synced Stripe invoices can report a balance that is wrong while every individual record behind it is right.

If you want your Stripe invoices and payments to land in QuickBooks already applied to each other, you can start a free trial.

Stripe collects. QuickBooks chases.

Stripe is good at collection, and it is worth being precise about what its tooling actually does, because the gap it leaves is the whole subject here.

Stripe's revenue recovery features are built around the failed payment. Smart Retries "automatically retry failed payments to prevent involuntary churn due to temporary issues", and Stripe describes retrying as "one of the most effective ways to recover revenue" precisely because "it requires no manual intervention from you or the customer." Alongside that sit the customer emails: Stripe can notify a customer "upon failed payment attempts", after an invoice is finalized, and "if a one-off invoice hasn't been fully paid." You can also turn on automatic reminders, where Stripe documents the setting as Send reminders if a recurring invoice hasn't been paid, with a choice of "before, when, or after the invoice is due."

Read that list again and notice its shape. Every item is scoped to one invoice or one payment attempt. The retry retries a charge. The reminder reminds about an invoice. Even the one-off reminder in the API is a call against a single invoice id.

That is the right design for involuntary churn, where the customer intends to pay and a card failed. It is not the tool for the other case, where a customer is simply behind on several invoices and needs to see the whole relationship on one page with a total at the bottom.

There is a vocabulary trap here worth clearing before going further. Stripe's own documentation defines invoices as "statements of amounts owed by a customer." In Stripe, then, a statement is an invoice. In QuickBooks it is a different document entirely: a summary of transactions already recorded, sent to remind a customer of a balance. Two systems, one word, two meanings. Everything below uses the QuickBooks meaning.

The three statement types, in Intuit's words

Intuit describes the purpose plainly: "Customer statements allow you to remind customers about upcoming payment deadlines, unpaid balances, or overdue invoices."

Creating one means picking a type, and the three types behave differently enough that the choice is most of the decision:

• Balance Forward "Lists invoices, payments, and the current balance for a specific date range."
• Open Item "Lists all unpaid invoices from a specific start date to the present."
• Transaction Statement "Lists all transactions recorded within a specific date range."

Three dates come with it: a Statement Date, a Start Date and an End Date. Statements are produced from the customer list, one at a time or in a batch, and sent by email after you have checked the addresses on the records.

One structural point matters more than it looks. A statement creates nothing. It has no amount of its own, posts no entry, and changes no balance. It is a report over transactions that already exist, which means every criticism of a statement is really a criticism of the records underneath it. That is why the second half of this post is about those records.

Which type to send when the invoices came from Stripe

Open Item is the collections document. It lists what is unpaid and nothing else, so the customer's eye goes to the only question you want answered. For a Stripe-first business this is usually the right monthly send, because Stripe has already emailed each invoice individually and the thing that adds information is the aggregate.

Balance Forward suits a running account. Invoices, payments and the resulting balance for a period, which is the familiar shape for a customer you bill continuously and who pays in irregular lumps. It answers "what happened between us last month" rather than "what is outstanding now."

Transaction Statement is for the argument. Every transaction in a window, paid or not. Reach for it when a customer disputes what they were charged or what was credited, or when a bookkeeper needs one page showing the full sequence rather than the residue.

There is a practical constraint on top of the choice. Intuit notes that statements will not generate for customers with no activity matching the dates you picked, so an empty run usually means the date window and not a broken feature.

A statement is only as true as the open balance underneath it

Here is the failure that makes statements interesting rather than routine, and it is not a Stripe problem or a QuickBooks problem. It happens in the join.

Money arrives in Stripe. The payment reaches QuickBooks. But if that payment is not applied to the invoice it paid, QuickBooks holds two facts that never meet: an invoice still showing its full open balance, and a payment sitting unlinked. Accounts receivable is overstated by the amount you have already been paid, and the statement, faithfully reporting what it was given, asks a customer to pay for something they paid for weeks ago.

Every record in that scenario is individually correct. The invoice is real. The payment is real. Only the relationship is missing, and a statement is a report about relationships.

Acodei's documentation is direct about which side of this it owns. When a Stripe invoice is paid, by a successful charge, by a manual payment according to your settings, or by a credit balance offset, Acodei creates the payment record in QuickBooks and applies it to the invoice it was created against. The documentation attaches a condition to that application: it requires QuickBooks Automatic Application to be on. The same requirement appears again in Acodei's best practices, which say to keep Automatic Application turned on in QuickBooks so payments and credit memos settle invoices automatically.

That is a setting on the QuickBooks side, in your file, not something the sync can decide for you. QuickBooks keeps its automation settings under Account and settings, then Advanced, then the Automation section. The most-discussed of them is Automatically apply credits, which Intuit documents as applying a credit to the oldest unpaid invoice, closing that invoice if the credit covers the balance and carrying any excess to the next oldest. Note the ordering rule in that description, because oldest-first is not always what you want on an account where invoices are disputed individually.

Acodei also runs validation when it records an invoice payment, and two of its four documented checks are about application specifically: that the correct payment amount is applied to the QuickBooks invoice, and that the payment is properly linked to the correct QuickBooks invoice. Both are documented as applying only when recording an invoice payment, which is worth stating precisely rather than reading as a general guarantee. A third check compares invoice numbers to prevent duplicate invoices being created in QuickBooks. The fourth, which compares the finished QuickBooks invoice to the Stripe invoice amount, is documented as applicable only if tax is enabled.

So the honest summary is that the sync applies payments and checks its own work at the moment of writing, and that the QuickBooks setting it depends on is yours to keep switched on. If you have ever wondered why a receivables report drifted after a settings change nobody logged, this is the mechanism.

Four ways a statement reports the wrong balance

Each of these produces a defensible-looking statement built on records that are individually fine.

The payment that never reached its invoice

The case above, and the most common one. It shows up as a customer who insists they paid, an aged receivable that never clears, and a bank balance that is right while receivables are wrong. The diagnostic takes seconds: open the invoice and look for the applied payment, then look at the customer for unapplied credits. Where the money is in the file but not on the invoice, the fix is application, not another payment. The mechanics of what a part-paid invoice should look like in QuickBooks are covered in detail in partially paid Stripe invoices.

One customer, two records

A statement is per customer record, not per human being. If the same customer exists twice in QuickBooks, they have two balances and two statements, each showing part of what they owe.

Acodei resolves the QuickBooks customer by name, matching case-insensitively but character-for-character, and keeps the link by the QuickBooks customer id once it has one. Change the name in QuickBooks and the link holds, because the id is what is stored. Change the name in Stripe and the next transaction finds no match, so a new QuickBooks customer is created. The full set of rules, including the vendor name conflict and the fallbacks when Stripe has no name at all, is in how Stripe customers become QuickBooks customers.

For statements, the consequence is short. Duplicate records mean split balances, and split balances mean statements that understate what is owed. Reviewing new customer records periodically is Acodei's own documented best practice, and the reason it matters is exactly this.

The currency split, which is designed and not a defect

If a Stripe customer's currency differs from the currency on the existing QuickBooks customer, Acodei creates a second record in the form of the customer name followed by the currency code, so "Acme" gains a sibling called "Acme - CAD", and the invoice posts against the matching one.

This one surprises people, so it is worth being clear about why it happens. QuickBooks fixes one currency per customer record. A customer you bill in two currencies therefore cannot be one record in QuickBooks, whatever any sync would prefer. The suffixed record is the designed consequence of a QuickBooks constraint, not a duplicate to be merged away, and Acodei's lookup keys on the QuickBooks customer id, so it survives suffixes that a plain name search would miss.

What it means for collections is concrete. A customer billed in two currencies has two records, two balances and two statements, and there is no single-page total for that relationship inside QuickBooks. Send both, or agree with the customer which currency the relationship is settled in and bill it there.

The invoice QuickBooks raised on its own

If a QuickBooks recurring transaction template is still billing a customer whose invoices now come from Stripe, the customer has two invoices for one month of service and the statement totals both. Nothing is malformed. There are simply two, and the statement is the document that finally puts them side by side in front of the customer.

The rule that falls out of it is the one from the glossary entry: pick the system that owns recurrence and switch the other one off for those customers. Templates remain the right tool for entries Stripe never produces, such as rent, loan payments and depreciation.

The sub-customer case, which is its own trap

QuickBooks lets you nest customers. Intuit describes the feature as assigning "customers who are also part of a group or large organization as the sub-customers of an existing 'parent' customer", and documents the shape of it: "While you can have unlimited sub-customers, parent accounts can only have sub-customers up to four levels deep." A sub-customer set to bill with the parent lets you "show the charges for the parent customer and the charges for the sub-customer on the same invoice".

Statements interact with that structure directly, and Intuit states the rule: "If a sub-customer is set to 'Bill with parent,' you must create the statement for the parent customer to include the sub-customer's transactions."

Now put the sync next to it. Acodei's documentation lists sub-customers under known limitations: QuickBooks sub-customers are not handled, and the sync is described as flat, which is to say the parent and child structure is not something a synced record joins.

For a franchise, an agency with client divisions, or anyone else running a parent and child structure, that combination is the thing to know before month end rather than during it. Your hierarchy still works for everything you raise inside QuickBooks. The Stripe-sourced records arrive beside it rather than inside it, so a parent statement will not sweep them in. If you need those records in the hierarchy, that is a QuickBooks-side reorganisation, and the vocabulary for it is in sub-customer.

What Acodei does here, and what it does not

Worth stating plainly in both directions, because the useful part of this integration is knowing where it stops.

What is documented. A finalized Stripe invoice becomes a QuickBooks invoice reproducing every line item and the tax lines, as far as your mapping settings allow. A paid Stripe invoice produces a payment or a credit memo in QuickBooks, applied to the invoice it belongs to, subject to the Automatic Application requirement above. A Stripe credit note becomes a credit memo, linked to the invoice where possible and otherwise posted to the customer. Invoice Sync is available on paid plans and is toggled per company rather than being on everywhere by default.

What is not documented, and therefore not claimed. Nothing in Acodei's product documentation describes creating, scheduling, sending or reading QuickBooks statements. Statements are a QuickBooks-side job, done by a person on a schedule they choose, and the sync's contribution is upstream of that: getting the invoices, payments and credit memos into the file correctly so that the balance a statement reports is the balance the customer actually owes.

There is one more limitation worth carrying into a collections process. Acodei does not update customer records after creation. Address and email captured at the moment the customer was created are what the record holds, so if statements are bouncing, the email on the QuickBooks customer is the thing to check, and it will not refresh itself from Stripe.

A month-end routine for chasing Stripe invoices from QuickBooks

Six steps, in the order that catches the most for the least effort.

1. Run the accounts receivable ageing first, not the statements. The ageing is your working document. Statements are what you send after it looks right.
2. Look for unapplied payments and credits. This is the highest-yield check in the list, because it is the one that produces a wrong statement rather than an ugly one. Cash in the file but not on an invoice overstates every balance it should have reduced.
3. Scan the customer list for near-duplicates. Same name with different punctuation, and names with a currency suffix. Decide which is the collections record for each relationship before you send anything.
4. Check for QuickBooks-raised invoices on Stripe-billed customers. A recurring template still firing is the most embarrassing line to put in front of a customer.
5. Pick the type deliberately. Open Item for a straight chase, Balance Forward for a running account, Transaction Statement when the customer is disputing history.
6. Send from the parent for sub-customers billed with the parent. Otherwise the transactions you meant to chase are not on the document.

None of this is exotic. It is the ordinary discipline of a receivables ledger, applied to a ledger whose entries were written by a sync rather than by hand, which changes where the errors come from but not what they look like once they are there.

Frequently asked questions

What is a customer statement in QuickBooks Online?

A summary document sent to a customer showing their account activity or unpaid balance. Intuit describes the purpose as allowing you "to remind customers about upcoming payment deadlines, unpaid balances, or overdue invoices." It is a report over transactions that already exist, so it posts nothing and changes no balance.

What is the difference between Balance Forward, Open Item and Transaction Statement?

Intuit defines them directly. Balance Forward "Lists invoices, payments, and the current balance for a specific date range." Open Item "Lists all unpaid invoices from a specific start date to the present." Transaction Statement "Lists all transactions recorded within a specific date range." Open Item is the usual choice for collections, because it shows only what is outstanding.

Can Stripe send a customer statement?

Not in the QuickBooks sense. Stripe's tooling is per invoice: automatic retries on failed payments, emails on failed attempts and finalized invoices, and reminders configured as "Send reminders if a recurring invoice hasn't been paid." Note also that Stripe's documentation uses the word statement for an invoice itself, defining invoices as "statements of amounts owed by a customer", which is a different document from a QuickBooks statement.

Why does my QuickBooks statement show invoices my customer has already paid?

Almost always because the payment reached QuickBooks but was not applied to the invoice. The invoice keeps its full open balance while the cash sits unlinked, so receivables are overstated by the amount already received. Acodei's documentation states that applying a payment to its invoice requires QuickBooks Automatic Application to be on, and its own best practice is to keep that setting enabled. Two of its four documented validation checks, both applying only when recording an invoice payment, are about whether the payment amount and the invoice link are correct.

Why does one customer have two statements with different balances?

Two records, two balances. Either the same customer exists twice, usually because a name changed on the Stripe side and the next transaction found no match, or the customer is billed in more than one currency. In the currency case Acodei creates a record in the form of the name followed by the currency code, because QuickBooks fixes one currency per customer record. That second record is the designed result of a QuickBooks constraint, not a duplicate to clean up.

Do sub-customer transactions appear on the parent's statement?

Only where the sub-customer is set to bill with the parent. Intuit states that "If a sub-customer is set to 'Bill with parent,' you must create the statement for the parent customer to include the sub-customer's transactions." Bear in mind that Acodei's documentation lists sub-customers as not handled and describes the customer sync as flat, so a synced record is an ordinary customer record rather than a node in a hierarchy.

Does Acodei create or send QuickBooks statements?

No, and nothing in its product documentation describes doing so. The sync writes invoices, payments and credit memos into QuickBooks and applies payments to the invoices they belong to. Producing and sending statements stays a QuickBooks-side task. What the sync affects is whether the balance on that statement is right.

My statement email bounced. Where does that address come from?

The email on the QuickBooks customer record, which Acodei populates when it creates the customer and does not update afterwards. Acodei's documentation lists no customer updates as a known limitation, so correcting the address in Stripe will not refresh the QuickBooks record. Fix it on the QuickBooks customer.

The short version

Stripe collects and QuickBooks chases, and the document QuickBooks chases with is the statement. Pick Open Item for a straight collections run, Balance Forward for a running account, Transaction Statement when history is in dispute.

A statement invents nothing, which is the good news and the bad news. It reports the open balance it is given, so every way that balance can be wrong is a way the statement can be wrong: a payment that never reached its invoice, one customer split across two records, a currency suffix that is designed behaviour rather than a duplicate, and an invoice raised by a QuickBooks template for a customer Stripe already billed.

Four of those five are visible in ten minutes on an ageing report, before anything reaches a customer. That check is the difference between a collections process that recovers money and one that costs you credibility with the people who already paid.

If you would rather Stripe invoices, payments and credit notes arrived in QuickBooks already applied to each other, start a free trial or see how the pricing works.