Partially Paid Stripe Invoices in QuickBooks

A customer owes you 12,000 USD. On the 3rd they send 5,000. The rest, they say, comes after their own quarter closes. You go looking for the invoice in Stripe expecting to find it marked something like "part paid", and what you find instead is an invoice that says open, exactly like every invoice nobody has paid a cent toward.

Your bookkeeper opens the Stripe Dashboard and sees the words "Partially Paid". Your developer queries the API and sees open. Both are reading the same invoice. Both are right.

That gap is not cosmetic. It decides what your accounts receivable should show for the next six weeks, and it is the reason partial payments are the single most commonly mis-booked thing in a Stripe-first billing operation.

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

Stripe has no partially paid status

Stripe documents five invoice statuses and only five. The invoice object defines status as "The status of the invoice, one of draft, open, paid, uncollectible, or void."

There is no sixth value for an invoice that has taken some money but not all of it. Stripe is explicit about where such an invoice sits, in its description of the invoice lifecycle:

If payment succeeds, Stripe updates the invoice status to paid. If payment fails or the invoice isn't fully paid, the invoice remains open.

And the definition of open itself carries the same idea: "The invoice has been finalized and still has a remaining balance."

So an invoice that has received 5,000 of 12,000 is open. An invoice that has received nothing is also open. An invoice whose card was declined four times is also open. If your reporting keys off status, those three situations are indistinguishable, and they are three very different conversations to have with a customer.

The three amounts that tell you what actually happened

The status will not tell you. The amounts will. Stripe puts three of them on every invoice, and their definitions are worth reading precisely rather than assuming.

• amount_due is "Final amount due at this time for this invoice." Stripe adds that it can be reduced by account credit, and that "The charge that gets generated for the invoice will be for the amount specified in amount_due."
• amount_paid is "The amount, in the smallest currency unit, that was paid."
• amount_remaining is "The difference between amount_due and amount_paid, in the smallest currency unit."

amount_remaining is not a field anybody sets. It is arithmetic, published so you do not have to do it yourself. On the invoice above it reads 700000, because Stripe works in the smallest currency unit and 7,000 USD is 700,000 cents.

That single field is the one your reconciliation should be reading. An invoice with status of open and amount_remaining equal to amount_due has been billed and ignored. An invoice with status of open and amount_remaining lower than amount_due has been billed and partly settled. Only the second one has cash behind it.

Two more amounts matter at the edges. amount_paid_off_stripe is "Amount, in the smallest currency unit, that was paid on the invoice outside of Stripe", which is how a wire or a cheque shows up against a Stripe invoice, and which has its own handling on the way into QuickBooks. And amount_overpaid is "Amount that was overpaid on the invoice", which Stripe says "is credited to the customer's credit balance". Overpayment is its own topic, but it is worth knowing the field exists, because a partial payment and an overpayment are the same reconciliation muscle pointed in opposite directions.

Why the Dashboard says something the API does not

The "Partially Paid" wording your bookkeeper is looking at is real, and Stripe documents it. It is a Dashboard presentation state, not an API status. Stripe describes the set plainly when explaining what happens after you detach a payment: "The invoice shows as Open, Past Due, Partially Paid, or Failed in the Dashboard."

All four of those are open underneath.

The same document notes another Dashboard-only distinction: "If an open non-subscription invoice is waiting for a payment that's initiated but still pending, it shows the Pending badge in the list of invoices. However, its details page shows the Open badge." Two screens in the same product, describing the same invoice with different words.

None of this is a defect. It is a UI being more helpful than a five-value enum can be. It matters only because people build month-end processes on screenshots and then automate them against the API, and the two do not agree about what a partially paid invoice is called.

How an invoice ends up part paid

There are two routes, and they behave differently.

The first is automatic collection failing to cover the balance, which is rare on cards and ordinary on bank debits.

The second is deliberate: somebody applies a payment to the invoice by hand. This is the common case for businesses that invoice on terms and take bank transfers or cheques. Stripe's rule for it is specific:

You can apply any payment to an invoice if the payment amount is less than or equal to the unpaid balance on the invoice, and the invoice is for the same customer as the payment. If you apply a payment that fully pays the invoice, the status moves to paid.

Read the second half carefully. The status moves to paid only when the payment fully pays the invoice. A 5,000 payment against a 12,000 balance is a legal application. It just does not change the status.

There is one constraint that surprises people, and it is the reason partial payments are recorded the way they are:

You can't apply a portion of a payment toward an invoice. You can only apply an entire payment toward an invoice, which means you can't apply a payment across multiple invoices.

So Stripe does not let you split one payment over two invoices, but it does let one invoice accumulate several whole payments. A part-paid invoice is not one payment cut in half. It is one or more complete payments that together come to less than the balance. That is why the invoice object exposes payments as a list, described as "Payments for this invoice", each entry linking a payment object to the invoice.

That distinction is the whole shape of the bookkeeping. You are not recording a fraction. You are recording a real payment that happens to be smaller than the bill.

What your QuickBooks A/R should show

Once you see it that way, the accounting stops being ambiguous.

The invoice is a receivable for its full amount from the moment it is issued. The partial payment is a payment, applied against that receivable. What remains in A/R is the difference. You do not reduce the invoice, you do not issue a credit, and you do not split the invoice into a paid one and an unpaid one. The invoice keeps its face value and the payment sits against it.

That treatment gives you the two things you actually need at month end. The A/R ageing shows 7,000 outstanding for that customer, which is what they owe. The revenue was recognised when the invoice was issued, so it is not moved by the payment timing. Cash is up by 5,000. Nothing else changes.

The failure mode worth naming: editing the Stripe invoice down to 5,000 so it looks settled. That produces books that balance and a customer who is never chased for 7,000. If the amount genuinely should come down, a credit note is the instrument for that, and it has different accounting from a payment. Stripe is direct about the difference, describing a credit note as something that "reduces the amount of a finalized invoice without voiding and replacing the original invoice", and noting that if a credit note "reduces the balance to zero, the invoice transitions to paid status".

A payment says money arrived. A credit note says less is owed. Partial payments are the first thing.

What Acodei documents, and where the documentation stops

Acodei's Invoice Sync is a one-way integration that mirrors Stripe invoices and subsequent payments into QuickBooks Online. It is available on paid plans and is toggled per company under Account Mapping, Premium Features.

Two documented behaviours cover the ordinary path. When a Stripe invoice is finalized, Acodei creates a QuickBooks Invoice that reproduces every line item, and tax lines, as the mapping settings allow. When a Stripe invoice is paid, 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, and the auto-application depends on QuickBooks Automatic Application being switched on, which Acodei's own best-practice guidance says to leave on for exactly this reason. Where the payment lands is set by your holding account configuration.

Now the honest part. Acodei's documentation describes the trigger and the record it creates. It does not separately spell out the case of one invoice settled by several charges over several weeks. charge.succeeded is in the documented trigger list and a partial payment is a successful charge, so the mechanism is there, but the multi-payment sequence is not written down as its own scenario, and this is a page about not guessing. Do not assume a particular number of QuickBooks payment records will appear against a part-paid invoice. Open the invoice in QuickBooks and look, the first time your business hits this case. If your volume of part-paid invoices is material, ask Acodei support to confirm the behaviour in writing rather than inferring it from one example.

One related path is documented, and it is worth knowing because it looks similar and is not. An invoice marked uncollectible and then later paid is handled explicitly: Acodei reopens it, removes the void transactions and processes the new payment. That is a specific recovery path for bad debt that came good. It is not a general statement about invoices reopened by other means.

The two checks that run when a payment is recorded

Acodei's validation rules include two that apply specifically when it records an invoice payment, and both are exactly the checks a careful bookkeeper would run by hand on a partial payment:

• Check that the correct payment amount is applied to the QuickBooks invoice.
• Check that the payment is properly linked to the correct QuickBooks invoice.

The second one is the one that saves you. An unlinked payment is the classic partial-payment error: the cash is in the books, the invoice still shows its full balance, and the customer appears to owe 12,000 when they owe 7,000. A payment sitting in QuickBooks unapplied to anything will overstate your receivables and understate nothing, which is the kind of error that survives a review because every individual number looks right.

A worked example

Invoice in_1QxAmpLe for a 12,000 USD consulting engagement, issued 1 March, terms net 30.

3 March. The customer sends 5,000 by bank transfer. You apply that payment to the invoice in Stripe.

In Stripe the invoice now reads: status open, amount_due 1200000, amount_paid 500000, amount_remaining 700000. The Dashboard badge reads Partially Paid. The payments list has one entry.

In QuickBooks the invoice still shows 12,000. A payment of 5,000 is applied to it. The open balance on the invoice is 7,000, and that is what the A/R ageing report shows against this customer.

2 April. The remaining 7,000 arrives and is applied.

amount_remaining goes to 0 and the status moves to paid, because this payment fully pays the invoice. In QuickBooks a second payment of 5,000 plus 7,000 brings the invoice balance to zero and it drops off the ageing.

Revenue in March: 12,000. All of it, on the invoice date, unmoved by either payment. Cash in March: 5,000. A/R at 31 March: 7,000. Three different numbers describing one transaction, and every one of them correct.

If your March revenue reads 5,000, somebody has booked the payment as the sale. That is the error this whole article exists to prevent.

What to check at month end

Four checks, in the order that catches the most for the least effort.

1. List open invoices where amount_paid is greater than zero. That is your part-paid population. It will not appear in any status-based report.
2. Confirm amount_remaining agrees with the open balance on the matching QuickBooks invoice. These are two systems doing the same subtraction. They should agree to the cent.
3. Look for unapplied payments in QuickBooks. Cash received but not linked to an invoice is the most common partial-payment defect, and it inflates A/R.
4. Check the age of the remainder, not the age of the invoice. An invoice that took half its value on day 2 and nothing since is a different collections problem from one that has been silent for 60 days, and your ageing report will not distinguish them.

One caution if anybody on your team has been detaching payments to fix mistakes. Stripe flags the downstream consequence directly:

If parts of your integration with Stripe assume that an invoice can't be reopened, evaluate whether you need to update your integration before reopening a paid invoice. For example, if you rely on Stripe events to update a downstream accounting system, confirm whether your integration is ready to handle an invoice being reopened.

Any Stripe-to-QuickBooks sync is a downstream accounting system driven by Stripe events. Treat unapplying a payment on an invoice that already synced as a change that needs checking on both sides, not a quiet correction. Note also that Stripe restricts the operation: "You can only unapply payments from invoices with collection_method = send_invoice."

Frequently Asked Questions

Does Stripe have a partially paid invoice status?

No. Stripe documents exactly five invoice statuses: draft, open, paid, uncollectible and void. A part-paid invoice stays open, because Stripe moves an invoice to paid only when it is fully paid. The words "Partially Paid" that you see are a Stripe Dashboard badge, not an API status. To find part-paid invoices programmatically, look for open invoices with amount_paid greater than zero.

What is the difference between amount_due and amount_remaining on a Stripe invoice?

amount_due is the final amount due at this time for the invoice, and it is what any generated charge will be for. amount_remaining is defined as the difference between amount_due and amount_paid. On an untouched invoice they are the same number. Once any payment lands, amount_remaining is the balance still outstanding and amount_due is unchanged.

Should a partial payment reduce the invoice in QuickBooks?

No. The invoice keeps its full value and the payment is applied against it, leaving the difference as the open balance in accounts receivable. Reducing the invoice would understate what the customer owes and would move revenue that was already correctly recognised. If the amount owed genuinely should be lower, a credit note is the right instrument, and it is a different entry from a payment.

Can one Stripe payment be split across two invoices?

No. Stripe states that you cannot apply a portion of a payment toward an invoice, only an entire payment, which means one payment cannot cover multiple invoices. The reverse works: a single invoice can accumulate several whole payments, and the invoice object exposes them as a payments list. For a payment created from a bank transfer, Stripe documents refunding it to the customer's cash balance and then applying the funds across different invoice amounts.

Does Acodei create a separate QuickBooks payment for each partial payment?

Acodei's documented triggers for creating a QuickBooks payment record are the invoice.paid and charge.succeeded events, and the payment is applied to the invoice Acodei already created when QuickBooks Automatic Application is on. The documentation describes that trigger and record rather than enumerating the case of one invoice settled by several charges, so check your own QuickBooks file the first time you hit a part-paid invoice rather than assuming a particular result.

Why does my A/R ageing show the full invoice when the customer has paid half?

Almost always because the payment reached QuickBooks but was not applied to the invoice. An unapplied payment leaves the invoice at its full open balance while the cash sits separately, so receivables are overstated by the amount already received. Acodei's validation includes a check that the payment is properly linked to the correct QuickBooks invoice, which is aimed at exactly this failure.

Does revenue change when a customer pays an invoice in instalments?

No. On accrual basis, revenue is recognised when the invoice is issued, and payments after that move cash and receivables only. A part-paid invoice affects the balance sheet across two periods and the income statement in one. If your revenue figure moves when a partial payment arrives, something is booking the payment as the sale.

The short version

Stripe has five invoice statuses and none of them means part paid. An invoice that has taken some money stays open, and the only reliable signal is amount_remaining, which Stripe publishes as the difference between amount_due and amount_paid. The Dashboard says "Partially Paid" because a five-value enum is not enough to run a collections process on.

In your books, nothing exotic happens. The invoice stands at full value, the payment applies against it, and the remainder is what the customer owes. Acodei's documented job is to mirror the invoice and the payments into QuickBooks and to check that each payment lands on the right invoice for the right amount. What it does not document is the multi-charge sequence, so verify that one against your own file rather than against an assumption.

Then run the check almost nobody runs: open invoices with a non-zero amount_paid. Those are the customers who have started paying you and stopped, and they are invisible to every report that keys off status.

Start a free trial and see your Stripe invoices and payments land in QuickBooks Online.

---

Stripe sources, fetched 2026-08-25: The Invoice object, How invoicing works, Payment application, Invoice Payments. Acodei behaviour is grounded in Acodei's Invoice Sync product documentation.