Stripe Invoice Revisions and the Second QuickBooks Invoice

Someone in billing tells you the invoice was wrong and they fixed it. You open QuickBooks expecting to find one corrected invoice. Instead the original is still sitting there, and there is a second invoice beside it, dated later. Nothing was overwritten.

Nothing has gone wrong. That is what a correction looks like in Stripe, by design, and the design has a reason behind it that is worth understanding before you try to tidy it away.

A finalized Stripe invoice cannot be edited. What Stripe offers instead is a revision, and a revision is not an edit and not quite a duplicate. It is a swap. The important part, the part that decides what your books see, is when the swap happens, because it is not when you start the correction.

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

Why the invoice is frozen in the first place

Stripe locks a finalized invoice deliberately, and says why in plain terms. After finalization you cannot change certain fields relating to the amount and the customer, and the stated reason is to satisfy the common tax-compliance requirement that finalized invoices be retained, as they were finalized, for a legally required minimum period.

There is a second warning alongside it that is easy to skim past. In some jurisdictions, Stripe notes, editing fields that modify the total amount due on an invoice "could render the invoice invalid". Not merely inaccurate. Invalid.

Seven customer fields are copied onto the invoice at finalization and frozen there: customer_address, customer_email, customer_name, customer_phone, customer_shipping, customer_tax_exempt and customer_tax_ids. Until finalization each of them mirrors the customer record. Afterwards they stop updating, permanently, which is why correcting a customer's own name on a finalized invoice is not a text edit but a procedure.

Stripe is equally direct about the API surface: you cannot use the Update endpoint "to edit most fields on an invoice after it has been finalized, including monetary amounts, discounts, or customer information".

So there are exactly three documented routes when something is wrong, and picking the right one is most of the work:

• The amount is wrong and the invoice stands. Use a credit note. Stripe allows these against any invoice in open or paid status.
• The invoice itself is wrong and can be replaced. Use a revision.
• The sale should not have happened. Void it, which is its own decision with its own consequences.

Stripe adds a compliance caveat worth repeating verbatim, because it cuts against the default: if you are based in the European Union, "you might want to void an invoice and issue a credit note instead of revising the original invoice", and it recommends consulting your own legal counsel.

The swap happens on finalization, not on creation

This is the mechanic that surprises people, and everything downstream follows from it.

You begin a revision by creating a new invoice with a from_invoice parameter pointing at the original. Stripe describes the result as "a new draft invoice that's linked back to the original as a revision". It duplicates all of the line items. Two things it does not do are worth noting: it does not duplicate credit notes, "which could result in a change to the amount due", and it does not pull in pending invoice items the way ordinary invoice creation does.

At this point nothing has happened to your accounting. The revision is a draft. The original is still open, still a live receivable, still exactly what your ledger thinks it is. You can edit the draft freely, add lines, fix the description, correct the customer.

Then you finalize the revision, and Stripe does two things at once:

1. Voids the original invoice.
2. Adds a latest_revision parameter to the original.

Stripe states the timing without ambiguity: it "voids the original invoice as soon as the first revision finalizes". The finalized_at timestamp on the revision is the current time, not the original's.

That single click is therefore two lifecycle events, not one. A new invoice finalizes, and an existing invoice voids, in the same moment. If you have been treating "revise the invoice" as a single conceptual action, this is the point where the mental model and the data part company.

Why that matters for a sync

Acodei's Invoice Sync documentation maps Stripe's invoice lifecycle to QuickBooks records event by event, and both halves of the swap appear on it.

The invoice.finalized event is documented as creating a QuickBooks Invoice that "reproduces every line-item, and tax lines, as allowed by the user's mapping settings", storing the Stripe ID against the QuickBooks invoice ID and applying suffix rules.

The invoice.voided event is documented as either voiding the QuickBooks invoice or creating a Credit Memo, with any attached credit notes 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, for the stated purpose of protecting closed periods. It is documented as auto-reversing if the invoice is later paid.

So each half of the swap is an event Acodei documents as a write into QuickBooks. One correction in Stripe, two documented writes. Your file ends up carrying more than one document for what the business thinks of as a single invoice, because the source system genuinely has more than one object, and reproducing that faithfully is the correct behaviour rather than a shortcoming.

What you get in QuickBooks therefore depends on a toggle you may have set for an unrelated reason. With Create Credit Memo on Void off, the original is voided in place. With it on, the original stays and a same-day Credit Memo offsets it, which is the safer shape if the original landed in a period you have closed. That is worth checking before the first revision rather than after.

The businesses most likely to need this cannot use it

Here is the constraint that reframes the whole feature for anyone billing on subscriptions.

You cannot revise an invoice attached to a subscription. Stripe states it flatly: after finalization you cannot edit invoices that have a subscription ID, and in the Dashboard the Edit invoice button is disabled for them. It extends further than it first appears, because you also cannot edit "any standalone invoices with subscription line items", and Stripe notes those standalone invoices are usually the ones created by pulling in pending proration line items.

Read that against who actually generates invoice corrections and the irony is sharp. Subscription businesses produce the most invoices, on the most automation, with the least human review before finalization, which is exactly the recipe for wrong invoices. They are the population excluded from the linked-revision mechanism.

What they get instead is the older procedure Stripe documents for changing a customer-related property, which is three manual steps: void the current invoice, duplicate the voided invoice, then update the customer information on the new one.

The outcome looks similar and is materially different in one respect. A revision sets from_invoice on the new invoice, documented on the invoice object as "Details of the invoice that was cloned", and latest_revision on the old one, "The ID of the most recent non-draft revision of this invoice". A manual void-and-duplicate sets neither. The two invoices are related only in the memory of whoever did it.

That distinction is invisible in QuickBooks either way, but it decides whether anyone can reconstruct the relationship later from Stripe. If you are on subscriptions and you correct invoices by hand, the link exists nowhere except your own notes, and it is worth putting the original's invoice number in the replacement's description while you still remember.

The rest of the constraints, and the one that bites

Stripe enforces several limits on revisions. Read as a group they describe a mechanism that only works on a genuinely quiet invoice:

• Only open or uncollectible. You cannot revise an invoice in void or paid status. Once money has landed, the revision route is closed and you are back to credit notes.
• One draft revision at a time. A second POST for the same original returns a 400.
• Nothing in flight. If the invoice has a payment intent in the processing state, you can neither create nor finalize a revision. Stripe names us_bank_account as the case that produces this, since ACH does not flip the invoice to paid when the attempt starts. So the slowest payment method blocks corrections for the longest window.
• The original must stay still. If the original becomes paid or void, or acquires a processing payment intent, while a draft revision exists, the revision cannot be finalized at all.
• No credit notes. You cannot create a revision for an invoice that has a credit note against it.

That last one deserves attention, because it collides with the obvious workaround. The natural instinct when an amount is wrong is to issue a credit note first and then fix the rest. Do that and you have disqualified the invoice from being revised. The order is not interchangeable: revise first, credit note second, or you have chosen credit notes for good.

It is also worth flagging a genuine tension in Stripe's own documentation here, because it is the kind of thing that stops an integration mid-build. The section describing what a revision duplicates says it does not duplicate credit notes, "which could result in a change to the amount due", which reads as though revising an invoice with credit notes is expected. The constraints section says you cannot revise an invoice that has one at all. Both statements are on the same page. Treat the constraint as binding, since that is the one describing the API's behaviour, and expect a 400 rather than a partial copy.

What the revision inherits, and what it quietly does not

Two inherited properties have real accounting consequences.

Automatic collection is switched off. Stripe documents that if the original invoice had auto_advance == true, the revision has it set to false. That field is documented as controlling whether Stripe performs automatic collection, and Stripe states that when it is false "the invoice's state doesn't automatically advance without an explicit action". So the replacement does not move itself along. If nobody notices, you have a receivable on your books that Stripe is not advancing, sitting at open and looking exactly like an invoice that is merely young. This is the single most likely way a revision costs you money rather than time.

The customer balance comes across, and possibly more of it. The revision's starting_balance and amount_due reflect any customer balance applied to the original, "plus any additional balance that is available on the customer object". The invoice object documentation says the same thing from the other side: for revision invoices, starting_balance also includes any customer balance applied to the original.

That second clause is the one to watch. A revision can come out at a different amount due than the original even if you changed nothing about the lines, because more customer credit was available by the time you finalized it. If you are checking that a correction changed only what you intended, compare the line items rather than the totals.

Acodei's handling of that balance is documented. By default it includes the applied balance as a line item on the QuickBooks invoice so the invoice reflects the exact amount Stripe charged. An admin setting, Skip "Applied Balance" as line item on Invoice, makes it ignore the balance and create the invoice at the full gross amount of subtotal plus tax instead, so accounts receivable carries the full value of the sale.

There is also a subtlety if you revise more than once. Stripe updates latest_revision on all previous revisions, and does so only on finalization, never at creation. So a chain of three corrections leaves every earlier document pointing at the final one, and a draft revision that you abandoned unfinalized has updated nothing at all.

Invoice numbers, and the duplicate problem

Finalization is what "ensures that an invoice number is present", so every finalized document in a revision chain has one. (For the full status machine either side of that moment, see what each Stripe invoice status means.) That puts two numbered QuickBooks invoices in the file for a single commercial transaction.

Acodei documents two mechanisms that bear on this. The first is the Invoice Number Suffix setting, which appends -AC1, -AC2 and so on to prevent duplicate-number errors when users also hand-enter invoices in QuickBooks, and which is documented as on by default. The second is a validation rule: Acodei compares invoice numbers to prevent duplicate invoices from being created in QuickBooks.

A second validation is worth knowing about precisely because of its documented scope. Acodei compares the finished QuickBooks invoice against the Stripe invoice amount to confirm they match exactly, and that check is documented as applying only when tax is enabled. On a revision, where the amount can shift through the customer balance described above, that is the check most likely to have something to say, and on a non-tax configuration it is not running.

One documented limitation applies here as everywhere: automated suffixing does not protect against manual renaming of invoices in QuickBooks. If someone tidies the numbers by hand after a revision lands, the protection is gone.

What is documented, and what is not

Being precise about the boundary matters more than usual on this topic.

Documented: that a finalized Stripe invoice creates a QuickBooks invoice; that a voided Stripe invoice either voids that QuickBooks invoice or produces a Credit Memo depending on the Create Credit Memo on Void toggle; that credit notes attached to a voided invoice are deleted first; that invoice numbers are suffixed by default and compared for duplicates; and how the applied balance is treated.

Not documented: anything about revision chains as such. The Invoice Sync documentation, which is where the invoice lifecycle is specified end to end, does not mention from_invoice or latest_revision and carries no statement that the integration recognises a revision as a revision, links the two QuickBooks documents to each other, marks one as superseding the other, or treats the pair differently from any other finalize-then-void sequence. We are not going to tell you it does. On the documentation available, each event is handled as the event it is.

The practical consequence is that the relationship between the two documents is yours to maintain. Both will be in QuickBooks and both will be correct as individual records. Nothing will label them as a before and an after.

What to actually do

If you correct Stripe invoices with any regularity, four things are worth settling once:

1. Decide the Create Credit Memo on Void behaviour deliberately, and decide it against your close calendar rather than your preferences. If corrections routinely arrive after a period closes, the Credit Memo shape keeps you out of a reopened period.
2. Check auto_advance after every revision. This is the failure that actually costs money. Build the habit of confirming the replacement invoice is being collected, because Stripe has switched that off for you.
3. Never issue the credit note first if there is any chance you will want to revise. That order is one-way.
4. Record the link yourself, especially on subscription invoices where Stripe will not record it for you. The invoice number of the original in the replacement's description costs nothing and answers the question someone will ask at year end.

And treat the two-document outcome as correct. The instinct to delete the voided one so the file looks tidy is the wrong instinct: the retention requirement that made the invoice immutable in Stripe is the same requirement that makes the voided copy worth keeping in QuickBooks.

FAQ

Can you edit a Stripe invoice after it is finalized?

No, not in any meaningful sense. Stripe locks fields relating to the amount and the customer at finalization, and states you cannot use the Update endpoint to edit most fields afterwards, "including monetary amounts, discounts, or customer information". The documented routes are a credit note to change the amount, a revision to replace the invoice, or a void.

What is a Stripe invoice revision?

It is a replacement invoice linked to the original. You create it by calling the invoice create endpoint with a from_invoice parameter, which produces a new draft that duplicates the original's line items. When you finalize that draft, Stripe voids the original and sets a latest_revision pointer on it.

When does Stripe void the original invoice?

When the revision is finalized, not when it is created. Stripe states that it voids the original "as soon as the first revision finalizes". Until that moment the original remains open and the revision is only a draft.

Why is there more than one document in QuickBooks after one correction?

Because there is more than one invoice in Stripe. A revision finalizes as a new invoice object and the original is voided in the same moment, and Acodei's documentation maps each of those events to its own QuickBooks record: a finalized invoice creates a QuickBooks Invoice, and a voided one either voids that invoice or produces a Credit Memo depending on the Create Credit Memo on Void setting. Which shape you see depends on that setting.

Does Acodei link the two QuickBooks documents to each other?

Not that we would claim. The Invoice Sync documentation specifies the invoice lifecycle event by event and does not mention from_invoice or latest_revision, nor does it state that one QuickBooks document supersedes another. On what is documented, each Stripe event is handled as itself, so the relationship between the two records is not something we would tell you is captured for you.

Can I revise a subscription invoice in Stripe?

No. Stripe documents that invoices attached to a subscription cannot be edited after finalization, and that the restriction also covers standalone invoices carrying subscription line items, which are typically the ones created by pulling in pending prorations. The fallback is the manual procedure: void the invoice, duplicate it, and correct the copy.

Can I revise an invoice that already has a credit note?

No. Stripe lists this as an explicit constraint. That makes the order irreversible in practice: if you might want to revise, revise before issuing any credit note, because issuing one first removes the option.

Will the revised invoice collect payment automatically?

Not by default. Stripe documents that a revision has auto_advance set to false when the original had it set to true, so automatic collection is off on the replacement. This is worth checking every time, since an uncollected replacement invoice looks identical to one that is simply waiting.

Can the revision come out at a different amount even if I changed nothing?

Yes. The revision's starting_balance and amount_due reflect the customer balance applied to the original plus any additional balance available on the customer object, so more available credit at finalization time can change the amount due without any change to the line items.

The point

A Stripe revision is a swap, not an edit, and the swap fires on finalization. One action, two lifecycle events, two documents that both belong in the record.

The version of this that goes wrong is rarely the extra document, which is correct and expected. It is the replacement invoice sitting at open with automatic collection quietly switched off, or the credit note issued in the wrong order that closed the revision route for good. Both are cheap to avoid once you know the mechanism fires where it does.

Start a free trial and see how each Stripe invoice event lands in your QuickBooks file.