Glossary

Stripe Invoice Status

A Stripe invoice status is the stage an invoice has reached in its lifecycle, one of draft, open, paid, void or uncollectible, and it determines both what you are still allowed to change and what your accounting system is told to record.

Also called: invoice status, draft, open, paid, void, uncollectible, Stripe invoice lifecycle, invoice states

Start a free trial View Pricing

Definition

Most people picture an invoice as a document. Stripe treats it as a state machine. The same invoice number can be a freely editable draft in the morning, a legally frozen open invoice by lunchtime, and a written-off bad debt by the end of the quarter, and nothing about the paper changed. What changed was the status.

That distinction is not academic for anyone keeping books. Stripe emits a webhook on each transition, not on the document, so the status change is the event an accounting integration reacts to. Your general ledger does not care that invoice INV-0041 exists. It cares that it moved from open to paid on the eleventh, because that is the moment revenue and cash have to be recorded.

Stripe documents five statuses. Two of them are described as terminal, meaning the invoice can never move again. As it turns out, only one of those two reliably is, and the gap between the two is the part that catches integrations out.

Key points

+Five statuses: draft, open, paid, void and uncollectible. Every invoice starts as a draft.
+Finalization is the hinge. It moves draft to open, assigns the invoice number, and freezes the amount and customer fields.
+A draft can be deleted. A finalized invoice cannot be, only voided.
+Void is genuinely terminal and can only be reached from open or uncollectible.
+Uncollectible is reversible: Stripe allows it to move on to void or paid.
+Paid is documented as terminal in one place and as reopenable in three others. The reopen path is real, and limited to invoices sent for payment rather than charged automatically.

The five statuses, and what each one still lets you do

Stripe defines a draft as an invoice that "isn't ready to use", and says all invoices start there. It is the only status in which you can edit essentially anything, and the only one from which the invoice can be deleted outright, with one carve-out: an invoice attached to a subscription cannot be deleted. Deletion is permanent, and Stripe emits an invoice.deleted event when it happens through the API.

Open means, in Stripe's words, "The invoice is finalized and awaiting payment". This is the working state. You can send it, you can pay it, and you can move it on to paid, void or uncollectible. What you can no longer do is rewrite it: Stripe permits changing "only some elements", such as the memo or metadata, and directs you to replace the invoice with a new one for anything substantive.

Paid means the invoice is settled. Worth knowing is that an invoice can reach paid without any payment succeeding. Stripe lists three such cases: a trial or free subscription, an amount due covered by the customer's credit balance or falling below the minimum charge amount, and an invoice marked as paid out of band. In those cases you receive an invoice.paid event but no invoice.payment_succeeded event, which is a genuine trap if your integration keyed off the wrong one.

Void means, per Stripe, "This invoice is canceled", and the column listing what you can do next reads in full: "No further actions".

Uncollectible carries Stripe's bluntest definition: "The customer is unlikely to pay the invoice. Normally, you treat it as bad debt in your accounting process." Unlike void it is not a dead end. Stripe explicitly allows moving an uncollectible invoice on to void or to paid.

Finalization is the transition that actually matters

Everything interesting happens at the draft-to-open boundary. Stripe lists five things finalization does: it allows the invoice to be paid, it ensures an invoice number is present, it makes certain properties immutable, it creates an incomplete payment intent, and it generates the hosted payment URL and the downloadable PDF.

The immutability is the half with accounting consequences, and Stripe is explicit about why. It exists "to satisfy the common tax-compliance requirement that finalized invoices be retained, as they were finalized, for a legally required minimum time period", and Stripe warns that in some jurisdictions editing fields that change the total due "could render the invoice invalid".

Seven customer fields are copied onto the invoice at finalization and frozen there: address, email, name, phone, shipping, tax exempt status, and tax IDs. Until finalization each of them simply mirrors the customer record. Afterwards they stop updating. That is why correcting a customer name on a finalized invoice is not an edit but a three-step procedure that Stripe spells out: void the invoice, duplicate it, then fix the customer information on the new one.

If you need to change the amount rather than the customer, Stripe points you at credit notes instead, which can be issued against any invoice in open or paid status.

One quiet behaviour lives on this boundary too. If an invoice finalizes with an amount due below the minimum chargeable amount, Stripe transitions it straight to paid and debits the difference from the customer's credit balance. No payment ever occurs, and the invoice is settled.

Void is terminal. Paid is documented both ways.

Void behaves exactly as advertised. Stripe calls it "conceptually similar to deleting or canceling" an invoice, but with a paper trail that keeps the number searchable, and states plainly that voided invoices "are treated as zero-value for reporting purposes, and aren't payable. This status is terminal, which means that the invoice's status can never change." You can only reach void from open or uncollectible, which means a paid invoice cannot be voided.

Paid is where Stripe's documentation contradicts itself, and the contradiction is worth knowing about before you build anything against it. The section on paid invoices says: "The customer has paid the invoice. This status is terminal, which means that the invoice's status can never change." But the status table one screen earlier lists the possible actions on a paid invoice as "Change the invoice status to open" and "Detach payments from invoice", and the lifecycle summary above it says you "can also change the status of a paid invoice back to open by unapplying payments from it".

Stripe's payment application documentation settles it: "After you unapply a payment from an invoice, the status moves back to Open." So paid is not terminal. Two constraints apply. Unapplying is only possible on invoices whose collection method is send_invoice, so an automatically charged subscription invoice really is stuck. And after a reopen, automatic collection is off by default, meaning no reminders are sent and no retries are attempted until you turn it back on.

Stripe itself flags the accounting risk here, and the warning is unusually direct: "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." Stripe then names one that does not, noting that its own NetSuite connector "doesn't support payment application on invoices", and that reopening in Stripe will not reopen the invoice in NetSuite.

The practical reading: treat a reopen as a real possibility on any invoice you send rather than charge, check what your ledger did with the original payment, and expect to reconcile it by hand.

Why the status, not the invoice, is what your books react to

Each transition has its own endpoint and its own webhook, and that is the level any sync operates at. Finalizing emits invoice.finalized and lands on open. Paying emits invoice.paid. Voiding emits invoice.voided. Marking a write-off emits invoice.marked_uncollectible. Detaching a payment emits invoice_payment.detached.

Read that list as a list of journal entries waiting to happen and the accounting picture falls out of it. Finalization is when a receivable comes into existence, and notably also when tax is reported, because finalization is what fixes the amount. Payment is when cash arrives and the receivable clears. Void reverses a receivable that should never have existed. Uncollectible keeps the receivable as a historical fact and writes it off as bad debt, which is a different entry with different tax treatment.

This is also why the two write-off statuses are not interchangeable even though Stripe puts them one line apart in the same dropdown. Void says the sale was never real. Uncollectible says the sale was real and the money is not coming. Those are different statements about your revenue, and only one of them is reversible if the customer surprises you a year later.

What each status writes into QuickBooks

Acodei's Invoice Sync is documented as a one-way mirror of Stripe invoices and their subsequent payments into QuickBooks Online, available on paid plans and toggled per company. Its documentation maps the lifecycle to QuickBooks records transition by transition, which is the useful way to read it.

Creation and finalization are listed together, as invoice.created and invoice.finalized, and both are documented as creating a QuickBooks Invoice that "reproduces every line-item, and tax lines, as allowed by the user's mapping settings". The overview describes this as happening when the Stripe invoice is finalized. Acodei stores the Stripe ID against the QuickBooks invoice ID and applies suffix rules, appending -AC1, -AC2 and so on, to avoid duplicate-number errors when someone also hand-enters invoices in QuickBooks. That suffixing is documented as on by default.

Payment is triggered by either invoice.paid or charge.succeeded, and creates a QuickBooks Payment that is auto-applied to the invoice. Acodei documents a prerequisite for that: QuickBooks Automatic Application has to be on. Where the payment lands is determined by your holding account setting.

Void is documented as either voiding the QuickBooks invoice or creating a Credit Memo, and if credit notes are attached to the Stripe invoice they are deleted first. Which of the two happens is governed by an admin toggle, Create Credit Memo on Void, described as using a same-day Credit Memo instead of voiding the QuickBooks invoice, with the stated purpose of protecting closed periods while still voiding in Stripe. Acodei documents that it auto-reverses if the invoice is later paid.

Uncollectible follows the same path as void. Acodei documents the reversal case explicitly: an invoice marked uncollectible and later paid is reopened, its void transactions are deleted, and the new payment is processed.

Zero-total invoices are a documented special case in both directions. An invoice carrying only zero-value line items is not synced at all. An invoice whose amount due is zero but which has at least one line item above zero syncs only if the Enable $0 Invoices admin setting is on, and its documented default is off.

On the way in, Acodei documents comparing invoice numbers to prevent duplicates, and comparing the finished QuickBooks invoice against the Stripe invoice amount to confirm they match exactly. That exact-match check is documented as applying only when tax is enabled.

One gap is worth stating rather than papering over. Acodei's documentation covers the uncollectible-then-paid reversal, but it does not address the paid-to-open path that Stripe's payment application feature creates. If you unapply a payment from a Stripe invoice, we would not want to guess what happens to the QuickBooks payment already recorded against it, so we do not claim a behaviour here. Check the record in QuickBooks directly, and treat it as a manual reconciliation until the behaviour is documented.

Want to see this on your own Stripe data?

Start a free trial

Frequently asked questions

What are the Stripe invoice statuses?

There are five: draft, open, paid, void and uncollectible. Stripe documents draft as an invoice that is not ready to use, open as finalized and awaiting payment, paid as settled, void as canceled, and uncollectible as an invoice the customer is unlikely to pay, which you would normally treat as bad debt.

Can a finalized Stripe invoice go back to draft?

No. Stripe documents no transition from open back to draft, and states that a finalized invoice cannot be deleted at all. To cancel it you change its status to void. To change the amount you issue a credit note, and to change customer details you void the invoice, duplicate it, and correct the copy.

Is a paid Stripe invoice really final?

Stripe's documentation says both things. The section on paid invoices calls the status terminal, but the status table, the lifecycle summary and the payment application guide all describe reopening a paid invoice by unapplying its payment, and the guide states that the status then moves back to Open. The reopen path is limited to invoices with a collection method of send_invoice.

What is the difference between void and uncollectible?

Void says the invoice should never have existed, and it is terminal: Stripe lists no further actions once an invoice is void. Uncollectible says the invoice was real and you have given up collecting, which is bad debt, and Stripe allows an uncollectible invoice to move on to void or to paid if the customer eventually pays.

Which Stripe invoice statuses create records in QuickBooks?

Acodei documents four transitions as writes. Creation and finalization create a QuickBooks Invoice reproducing the line items and tax lines. Payment, triggered by invoice.paid or charge.succeeded, creates a Payment auto-applied to that invoice. Void either voids the QuickBooks invoice or creates a Credit Memo, depending on an admin toggle. Uncollectible follows the void path.

Why did my Stripe invoice become paid without a payment?

Stripe documents three cases where an invoice reaches paid with no payment intent succeeding: a trial or free subscription, an amount due covered by the customer credit balance or below the minimum charge amount, and an invoice marked as paid out of band. You receive an invoice.paid event but no invoice.payment_succeeded event.

Does a zero-dollar Stripe invoice sync to QuickBooks?

It depends which kind. Acodei documents that an invoice containing only zero-value line items is not synced. An invoice whose amount due is zero but which carries at least one line item above zero can sync, but only when the Enable $0 Invoices admin setting is turned on, and that setting is documented as off by default.

When does Stripe report tax on an invoice?

At finalization, not at payment. Finalization is what fixes the amount and makes the invoice payable, and Stripe describes the transition as happening before the invoice is paid. That is why the finalization moment, rather than the payment, is the one that matters for a tax period boundary.

What customers say about running Stripe through Acodei

★★★★★

“If you're testing out all the different Stripe/QuickBooks integration apps right now, let me save you some time. This one is the best one by far.”

RyanOwner at Indie Music Academy