Stripe Invoice Overpayments in QuickBooks Online

Your Stripe invoice says paid. The customer says they paid twice. Both are true, and the second payment is not on the invoice anywhere, because Stripe took it off the invoice the moment it landed.

Overpayment is one of the few events in Stripe billing where the money genuinely moves out of the document you are reconciling and into a different object entirely. The invoice closes clean. Your bank sees both payments. And the difference sits on the customer record as credit you now owe them, waiting for an invoice that has not been written yet.

This post follows the excess from the moment it arrives to the moment it comes back, and says what your QuickBooks file shows at each step.

Start a free trial and see how your Stripe invoices arrive in QuickBooks Online.

An overpayment is not just a bigger payment

Stripe has a dedicated field for it. On the Invoice object, amount_overpaid is documented as "Amount that was overpaid on the invoice. The amount overpaid is credited to the customer's credit balance."

Read that second sentence slowly, because it is the whole story. The excess is not held against the invoice. It is not a negative balance on the invoice. It is not sitting in a suspense bucket waiting for someone to allocate it. Stripe moves it, automatically, to the customer.

The mechanism is documented on Stripe's partial payments page: "When an overpayment happens, Stripe automatically credits the excess funds to the customer's credit balance. The balance transactions for these credits have an invoice_overpaid type."

So an overpaid invoice produces two things: an invoice with a clean paid status whose amount_paid exceeds its total, and a credit ledger entry against the customer. There is also an invoice.overpaid webhook, which exists precisely because Stripe expects you to want to do something about this rather than let it sit.

That split is why overpayments survive a month-end review. The invoice reconciles. Nothing about the invoice looks wrong. The liability you have just taken on lives somewhere your invoice report does not look.

How an invoice gets overpaid in the first place

Overpayment is not something a customer can do by fat-fingering an amount on the payment page. Stripe is explicit that "your customers can't pay a partial amount on the Hosted Invoice Page." The hosted page pays the invoice, in full, once.

It happens when an invoice has more than one payment attached to it. Stripe puts it plainly: "If an invoice has multiple open payments, it's possible to inadvertently overpay the invoice. You can avoid overpayment by canceling payments that you don't need."

That comes out of the partial payments feature. To take a payment smaller than the invoice total, you create a PaymentIntent and attach it with attach_payment, and each attempt is stored in the invoice's payments list. Two attached PaymentIntents that both succeed will both be applied, and if their sum exceeds the total, the difference is overpaid.

In practice, there are three ordinary ways this happens to a real business:

• You attach a PaymentIntent for a partial payment, the customer separately pays the full invoice through the hosted page or a saved card, and both settle.
• A customer's accounts-payable system pays the invoice twice, once by card and once by bank transfer, and both are attached. The wire half of that has its own handling on the way into QuickBooks.
• You attach a payment to cover an invoice, cancel nothing when the customer's own payment arrives, and let both complete.

There is a useful boundary here. Partial payments, and therefore this flavour of overpayment, apply to invoices Stripe sends rather than charges. Stripe states that "partial payments aren't supported for subscription invoices that are charged automatically," where collection_method is charge_automatically. If your Stripe account is pure card-on-file subscription billing, driven by automatic collection, you are largely out of range. If you invoice businesses that pay on terms, you are squarely in it.

Where the excess actually goes

The customer credit balance is a ledger, not a number Stripe keeps for convenience. Stripe describes it as "computed from a ledger, an immutable list of debit and credit transactions," which "provides an audit trail of transactions for the customer."

The sign convention catches people every time. Per Stripe's customer balance documentation: "Negative values are treated as a credit (a reduction in the amount owed by the customer) that you can apply to the next invoice. Positive values are treated as a debit (an increase in the amount owed by the customer to you)."

So an overpayment drives the customer balance more negative. A customer who has overpaid you by 2,400 USD sits at a balance of -240000 in the smallest currency unit. That is money you owe them, expressed as a negative number, which is the opposite of what an accountant's instinct says a negative balance means.

Three more rules matter for reconciliation:

• "The invoice balance automatically applies to the next invoice finalized for the customer." You do not choose when it comes back. The next finalized invoice takes it.
• "A credit invoice balance is applied up to the invoice total amount." A credit larger than the next invoice does not create a refund. It is consumed to the extent the invoice can absorb it and the rest stays on the ledger.
• "The invoice balance and the invoice currencies must match." A USD credit will not reduce a EUR invoice.

Each application leaves its own trace. Stripe's customer balance transaction types include applied_to_invoice, which "traces the application of credit against a linked Invoice," and unapplied_from_invoice, which traces the reversal of one. Combined with the invoice_overpaid type on the way in, the round trip of a single overpayment is visible end to end in the customer's balance history in the Dashboard.

The customer balance itself has more sources than overpayments, credit grants are a different mechanism again, and a credit note is a deliberate reduction of an invoice rather than a surplus against one. Overpayment is the only one of the four that arrives without anybody deciding to create it.

What your QuickBooks file shows on the day it happens

Here is where honesty matters more than completeness.

Acodei's documented behaviour covers two moments in an invoice's life. When a Stripe invoice is finalized, Acodei creates a QuickBooks Invoice reproducing every line item, and tax lines, as the mapping settings allow. When a Stripe invoice is paid, whether by a successful charge, a manual payment per your settings, or a credit balance offset, Acodei creates a QuickBooks Payment Receipt or Credit Memo and applies it to the invoice it already created. The documented triggers for that payment record are the invoice.paid and charge.succeeded events, the automatic application depends on QuickBooks Automatic Application being switched on, and where the payment lands is set by your holding account configuration.

What is not documented anywhere in Acodei's product documentation is a path that turns an overpayment itself into a QuickBooks credit, a customer-level credit memo, or an unapplied payment sitting on the customer. There is no documented behaviour for the invoice.overpaid event.

So the honest answer for the day the overpayment lands is this: the excess is visible in Stripe, on the customer's credit balance, and QuickBooks has no record that names it as a credit you owe. Your A/R is not wrong. The invoice was raised and settled. But the liability that Stripe created alongside it has not been asked to appear in your books, and if you want it there this period, somebody puts it there by hand.

This is deliberate rather than accidental. Acodei's documentation records that two-way credit balance sync was considered and not pursued, with the note that customer balances can still be tracked in Stripe over time. Knowing that a gap is a decision rather than a bug changes what you do about it: you build a month-end check, not a support ticket.

When the money comes back

The QuickBooks half of this story is real, and it happens on the next invoice rather than this one.

Acodei's Invoice Sync documentation covers it directly. Stripe may apply a customer balance, positive or negative, to reduce or increase the amount_due on an invoice, and the documentation names the source explicitly: this typically comes from past overpayments or manual adjustments in the Stripe dashboard. That is your excess, returning.

What lands in QuickBooks depends on one admin setting:

• By default, Acodei includes the applied balance as a line item on the QuickBooks Invoice, so the record reflects the exact amount Stripe charged. Your A/R shows what the customer actually owed after the credit.
• With "Skip 'Applied Balance' as line item on Invoice" enabled, Acodei ignores the applied balance and creates the invoice at the full gross amount, subtotal plus tax, so QuickBooks A/R reflects the full value of the sale. The setting is an admin toggle, relevant only in Invoice Sync mode, and its stated purpose is cleaner invoice presentation when credit balances confuse users.

Neither is the right answer universally. The default keeps QuickBooks agreeing with Stripe cash for cash. The alternative keeps QuickBooks agreeing with what you actually sold. If your revenue reporting is built on invoice totals, the difference is not cosmetic, and a credit applied under the default will make a period look smaller than the sales you booked.

The case where the next invoice disappears

There is a sharper version of this worth planning for, and it comes from two documented rules colliding.

A credit is applied up to the invoice total. So a credit large enough to cover the whole of the next invoice takes the whole of it, and that invoice finalizes with an amount_due of zero while still carrying real line items.

Acodei's documentation is specific about what happens to invoices like that. There is an admin setting, "Enable $0 Invoices," which allows invoices whose amount_due is zero and which have at least one line item greater than zero to sync. Its documented default is off. Invoices consisting only of zero-value line items are skipped regardless.

Put those together. A customer overpays by enough to cover next month, next month's invoice finalizes at zero due, and on default settings that invoice is not synced. The sale exists in Stripe. QuickBooks has no invoice for the period. Nothing errored. The wider behaviour of zero dollar and negative invoices is worth reading if you hit this more than once.

One caveat, stated rather than papered over: Acodei's documentation also says that an invoice paid by a credit balance offset produces a QuickBooks Payment Receipt or Credit Memo applied to the previously created invoice. It does not say which behaviour governs when the offset takes the invoice to zero and the zero-invoice setting is off. That combination is not covered, so this post does not claim an outcome for it. If you bill customers who carry large credits, test it on your own account before you rely on either reading.

Refunding an overpayment instead

Sometimes the right answer is to give the money back rather than hold it. Stripe documents a specific sequence for that, and one step in it is easy to skip:

1. Listen for the invoice.overpaid webhook.
2. Use the amount_overpaid field to determine the refund amount.
3. Retrieve the customer's invoice_credit_balance. Stripe's own instruction: "If the customer's balance is less than the refund amount, the overpayment isn't refunded because it might be applied to another invoice."
4. Adjust the customer's balance and subtract the overpayment credit.
5. Create a refund.

Step three is the one that protects you from paying twice. Between the overpayment landing and somebody deciding to refund it, another invoice may have finalized and eaten the credit. Refunding the original excess at that point hands the customer money they have already spent with you.

Step four matters just as much in the other direction. A refund that does not reduce the credit balance leaves the credit live, and it will still be applied to the next invoice. You will have refunded the overpayment and discounted the next sale by the same amount.

Note also that a credit balance is not a thing Stripe pays out on its own. Adjustments are made by creating a reversing transaction: Stripe states you "can only undo a transaction by creating a corresponding, reversing transaction." The balance moves because somebody moves it.

A worked example

A design agency invoices a client 2,400 USD on terms, using send_invoice collection.

The client's AP system pays it by ACH. Separately, the client's office manager pays the same invoice by card through the hosted invoice page. Both succeed.

In Stripe:

• amount_paid is 480000, amount_overpaid is 240000, and the invoice status is paid.
• A customer balance transaction of type invoice_overpaid credits the customer 2,400 USD.
• The customer balance moves to -240000.

In QuickBooks, on that day, with Invoice Sync running: one invoice for 2,400 USD, and the payment records Acodei creates from the documented invoice.paid and charge.succeeded triggers, landing in the holding account you configured. The 2,400 USD of client money you are now holding as credit is not named as such anywhere in the file.

The next month, the agency invoices 3,000 USD. Stripe applies the credit to the next finalized invoice: starting_balance is -240000, and amount_due becomes 60000. The customer pays 600 USD.

On default settings, the QuickBooks invoice carries the applied balance as a line item and reflects 600 USD, matching what Stripe charged. With the skip setting enabled, the QuickBooks invoice is written at the full 3,000 USD gross.

Same two months, same cash, two different revenue pictures. Neither is a bug. Both are a configuration choice somebody made once, possibly before you arrived.

Change one number and you get the trap from the previous section: invoice the client 2,400 USD instead of 3,000, and amount_due finalizes at zero.

What to check at month end

Four checks, none of which requires an engineer:

• Filter Stripe invoices where amount_overpaid is greater than zero for the period. This is the only report that names the event directly.
• Review customer balances that are negative. In the Dashboard, that is the Customer invoice balance section on the customer record, where "View details" gives you the transaction history behind the number. Negative means you owe them.
• Reconcile deposit totals to invoice totals rather than to each other. An overpayment makes cash in exceed invoiced revenue for the period, which is the symptom you will actually notice first, and it can surface as an unreconciled payment if you are matching payment for payment.
• Check whether an expected invoice is missing from QuickBooks before assuming a sync problem. If the customer carried a credit, the invoice may have finalized at zero due, and the $0 invoice setting decides whether it syncs.

If you carry material customer credits and want them on the balance sheet as the liability they are, that is a manual journal entry each period, sized from the sum of negative customer balances. Nothing in the documented sync will create it for you.

Frequently Asked Questions

Does an overpaid Stripe invoice show as overpaid in QuickBooks?

No. The overpaid amount does not stay on the Stripe invoice, so it is not carried onto the QuickBooks invoice either. Stripe documents that the amount overpaid is credited to the customer's credit balance, which leaves the invoice itself settled at its own total. What reaches QuickBooks is Acodei's documented output: an invoice created when the Stripe invoice was finalized, and a payment record created when it was paid.

Will Acodei create a QuickBooks credit memo when a customer overpays?

Acodei's product documentation does not describe any behaviour triggered by an overpayment, and there is no documented handling of the invoice.overpaid event. What is documented is what happens when the credit is later applied to another invoice, which is the applied balance treatment on that next invoice. Treat the overpayment itself as visible in Stripe only, and decide deliberately whether to record it in QuickBooks by hand.

Why did my next Stripe invoice charge less than the amount I invoiced?

Almost certainly a customer credit balance being applied. Stripe applies the invoice balance automatically to the next invoice finalized for that customer, up to the invoice total. Check starting_balance on the invoice: if it is negative, a credit was applied, and the amount_due you were charged is the total less that credit.

Can a customer overpay an automatically charged subscription invoice?

Not through the partial payments route. Stripe states that partial payments are not supported for subscription invoices that are charged automatically, where collection_method is charge_automatically. Overpayment through multiple attached payments is a risk on invoices you send for the customer to pay, not on card-on-file subscription billing.

Does the QuickBooks invoice total have to match the Stripe invoice exactly?

Acodei runs a validation that compares the invoice generated in QuickBooks against the Stripe invoice amount, and that check is documented as applying only when tax is enabled. Separate checks confirm that the right payment amount was applied to the QuickBooks invoice and that the payment is linked to the correct invoice, and those run when an invoice payment is recorded.

How do I stop overpayments happening at all?

Cancel payments you no longer need. Stripe's guidance is direct: where an invoice has multiple open payments, overpayment becomes possible, and the way to avoid it is to cancel the ones you do not need. For any payment other than the invoice's own default PaymentIntent, you can move it from open to canceled by canceling the associated PaymentIntent.

The short version

An overpayment splits into two records. The invoice stays clean and settles at its own total. The excess becomes customer credit, which is a liability you owe, recorded in a ledger Stripe keeps on the customer rather than on the invoice.

Acodei's documented sync covers the invoice and the payment. It does not document anything that turns the overpayment itself into a QuickBooks record, and two-way credit balance sync is documented as not pursued. The credit reappears in your books later, on the next invoice that absorbs it, and one admin setting decides whether that invoice shows the reduced amount Stripe charged or the full value of the sale.

Get that setting right for how you report revenue, watch negative customer balances the way you would watch any other liability, and the only surprise left is the invoice that finalizes at zero due and quietly does not sync.

Start a free trial and see your Stripe invoices, payments and applied balances land in QuickBooks Online the way your close expects them.