Voiding a Stripe Invoice in a Closed QuickBooks Period

You closed March three weeks ago. The numbers went to your accountant, the sales tax got filed, and the month is done. Then someone on your team opens a March invoice in Stripe, notices the billing address is wrong, clicks Edit invoice, and fixes it.

Nobody made a decision about closed periods. But one just got made, because that click voided the March invoice, and the void has to land somewhere in QuickBooks.

This post is about where it lands, why the answer is uncomfortable, and the one Acodei setting that changes it.

Start a free trial and see how your Stripe invoices post into QuickBooks.

The two-sentence version

A void is an edit to a document that already exists. QuickBooks changes that document's amount to zero and leaves it exactly where it sits, on its original date. If that date is inside a month you have already closed, your closed month just changed.

A credit memo is not an edit. It is a new document, dated today, that settles the old one. The closed month keeps the numbers you closed it with.

Everything below is the long way round to that distinction, and to the fact that Stripe hands you far more voids than you think it does.

What "closed" actually means in QuickBooks Online

Closing the books in QuickBooks Online is a soft lock, not a hard one, and the distinction matters for everything that follows.

Intuit describes the feature plainly: "Lock your books to stop changes to past transactions. This helps keep your financial data accurate for tax filings, audits, and reports." You set a closing date, and you pick one of two security options: allow changes after viewing a warning, or allow changes after viewing a warning and entering a password.

Read those two options carefully. Neither of them is "prevent changes." The lock is a speed bump with an audit trail, not a wall. Intuit's guidance on editing closed books confirms who gets to drive over it: "Only admins can make these changes."

And because the lock is soft, QuickBooks gives you a way to find out what went through it. Intuit's instruction is to "use an Exceptions to Closing Date report to see any changes made after you close your books." That report is the single most useful thing in this post if you do nothing else. It is the list of every transaction that changed inside a period you had already signed off.

The practical consequence: an integration writing into QuickBooks on your behalf is not stopped by a closing date. It is recorded. Your March can move, and the only place that says so is a report most businesses have never opened.

What a void does to a QuickBooks transaction

Intuit is specific about the mechanics. From "Void or delete transactions in QuickBooks Online and QuickBooks Desktop": "Any transaction you void has its amount changed to zero, and is marked VOID in your records."

That is the whole problem in one sentence, and it is worth slowing down on the verb. The amount is changed. Not offset, not reversed, not counterbalanced by a second entry. The existing document is rewritten in place.

Intuit frames this as the responsible choice, and for recordkeeping it is: "For recordkeeping, voiding is better than deleting. It keeps a record of the transaction in your books without changing your totals." A deleted transaction disappears from everywhere except the audit log. A voided one stays visible, numbered, and searchable, which is what an auditor wants.

But "keeps a record" and "keeps your March P&L unchanged" are different promises, and only the first one is being made. The voided invoice still carries its original date. A March invoice voided in May is a March document that now reads zero. Run March revenue today and you will get a different answer than you got when you closed it.

This is the mirror image of a refund. A refund is a new transaction on the day it happens, so it hits the period it happens in. A void reaches back to the period the original belongs to. Same intent, opposite accounting behavior, and nothing in either interface tells you which one you picked.

The part nobody plans for: Stripe generates voids on its own

Here is where this stops being an edge case.

Most people assume a void is a deliberate act. You look at an invoice, decide it should never have existed, and cancel it. That is real, and if you want the full treatment of when to void versus when to write something off as bad debt, our post on void versus uncollectible Stripe invoices covers that decision and what each one does to your tax reporting.

But deliberate voids are not the ones that surprise your books. The ones that surprise your books come from correcting an invoice.

Stripe does not let you meaningfully edit a finalized invoice in place. Its invoicing documentation says a finalized invoice allows changes to "only some elements," and for anything more: "To make more substantive changes, create a new invoice and void the old one."

That is a documented instruction, not a workaround, and Stripe's Dashboard automates it. From the guide to editing finalized invoices: "Stripe lets you revise a finalized invoice in open or uncollectible status." You click Edit invoice, change the line item or the discount or the description, click Update invoice, and then, in Stripe's own words:

When you click Update invoice, Stripe finalizes the new invoice and voids the old one.

The person doing this is not thinking about voids. They are fixing a typo. Stripe's interface calls the action "Edit invoice," and the customer-facing email describes it as an update. The void is an implementation detail of the revision, invisible unless you go looking for it in the invoice History section.

So the realistic path into this problem is not an accountant deciding to cancel a January invoice in April. It is a support rep correcting a line item on a February invoice in April, generating an invoice.voided event for a February document, and never knowing they touched a closed month.

Two boundaries worth knowing on that revision path, both from the same Stripe page. You cannot revise invoices attached to subscriptions after finalization, so recurring billing does not produce these. And you cannot revise an invoice in void or paid status, which means the exposure is specifically your unpaid open invoices, the ones most likely to still be getting corrected weeks after they were issued.

What Acodei writes when the void arrives

First, the scope. This question only exists if you have QuickBooks invoices at all, which means Invoice Sync. Acodei's Invoice Sync is a one-way mirror of Stripe invoices and their payments into QuickBooks Online: when a Stripe invoice is finalized, Acodei creates a QuickBooks Invoice that reproduces every line item and the tax lines, as allowed by your mapping settings. It is available on paid plans and toggled per company. If you are running the sales receipt flow instead, there is no QuickBooks invoice to void and this whole question is moot.

With Invoice Sync on, the invoice.voided event causes Acodei to void the QuickBooks invoice or create a Credit Memo. If credit notes are already attached to that invoice, they are deleted first, because the credits have to come off before the void can land cleanly.

The default behavior, then, includes the case this post is about: a void in QuickBooks, on the original invoice, on its original date, inside your closed month.

invoice.marked_uncollectible is documented as the same handling, which means writing off bad debt on an old invoice has the same reach. That is a second door into the same room.

The setting that changes the answer

Acodei has a toggle for exactly this, and its documented purpose names the problem directly.

Create Credit Memo on Void uses a same-day Credit Memo instead of voiding the QuickBooks invoice. Acodei's documentation states its reason for existing in one line: it protects closed periods while voiding invoices in Stripe.

Structurally, that is the right shape. The original March invoice stays exactly as it was, at its original amount, on its original date. A Credit Memo appears with today's date, carrying today's period, and settles the invoice balance. March closes as March. The correction lands in the month you actually made it, which is where an accountant would have put it by hand.

A credit memo behaves like a payment that came from you rather than from the customer. It clears the balance without money moving. For that clearing to happen automatically, QuickBooks Automatic Application needs to be on, which is Acodei's documented best practice for exactly this reason.

Two honest caveats before you go asking for it.

It is an admin-side setting. Acodei documents it among the advanced toggles in the Acodei admin panel, not as a checkbox in your own dashboard, so turning it on is a conversation with support rather than something you flip this afternoon.

And it is not free of consequences, which brings us to the clause a careful reader will already be circling.

"What if the invoice gets paid after all?"

This is the right objection. If you replaced a void with a credit memo, you now have an open invoice that has been credited to zero. If the customer pays it next month, you have an invoice, a credit memo, and a payment all pointing at the same money.

Acodei's documentation answers it in four words: the credit memo auto-reverses if the invoice is later paid.

That is a meaningfully better answer than the default path can give. A voided QuickBooks invoice is a rewritten document, and unwinding it means finding what was changed and changing it back. A credit memo is an ordinary document that can be reversed by removing it, which is why the reversal can be automatic in the first place.

It also matches how Stripe behaves one layer up. A voided Stripe invoice is terminal, so a payment on it is not a case Stripe will ever represent. An invoice marked uncollectible can go back to paid, and Acodei documents the matching path for that case: reopen the invoice, delete the write-off transactions, and process the new payment.

Notice what never happens anywhere in that sequence. The original March invoice is not rewritten when the write-off is recorded, and it is not rewritten when the write-off is undone. It sits there at its original amount the entire time while separate documents come and go around it. That is the property worth having, and it is the one the default path gives up.

What to actually do

Find out whether this has already happened to you. Run the Exceptions to Closing Date report in QuickBooks. If voided invoices are showing up in months you had closed, this is not hypothetical for your business, and the report will tell you how often.

Decide whether corrections are common in your billing. If your team routinely fixes finalized Stripe invoices, you are generating voids as a matter of course, and the volume is roughly your correction rate rather than your cancellation rate. That is the number that should decide whether the toggle is worth a support conversation.

Set the closing-date password rather than the warning-only option. It will not stop an integration writing through the API, but it stops a human clicking through a dialog they have stopped reading, and it makes the deliberate exceptions deliberate.

Do not fix these by hand in QuickBooks. Acodei's documented guidance is to resync from the Data Feed rather than manually altering synced transactions, and hand-editing a synced document is how you end up with two systems that disagree and no record of which one moved. If you need to know what happened to one specific invoice, the Data Feed is where to look rather than reasoning about it from the outside.

Talk to your accountant about the direction, not the mechanics. Whether a given correction belongs in the original period or the current one is a judgment call about materiality and about what you have already filed. The point of this post is that the integration makes that call for you by default, silently, and that you can change which way it goes.

The general lesson

Every accounting integration has a small number of operations that write backwards in time, and they are rarely labeled as such. Voids are the clearest example because the word sounds like cancellation, which sounds like it happens now, when in fact it happens then.

The tell is always the same question: does this action create a new document, or change an existing one? New documents are safe, because they carry today's date and land in an open period. Changes to existing documents carry the original date, and they go wherever that date lives, including into a month you have already signed off, filed, and stopped thinking about.

Stripe and QuickBooks each behave sensibly on their own terms. Stripe voids the old invoice because that is how it preserves a paper trail while replacing a document. QuickBooks zeroes the transaction in place because that is how it keeps the record without deleting it. The friction is entirely in the seam between them, which is the seam your integration is standing in.

Start a free trial and see exactly what Acodei writes into QuickBooks for every Stripe invoice event.

Frequently asked questions

Does voiding a Stripe invoice change my QuickBooks numbers for a closed month?

It can. Acodei's default handling for invoice.voided is to void the QuickBooks invoice or create a Credit Memo. A voided QuickBooks transaction has its amount changed to zero and stays on its original date, so if that date falls inside a period you have already closed, the totals for that period change. A credit memo instead posts as a new document dated today, which leaves the closed period alone.

Does closing the books in QuickBooks Online stop an integration from writing to a closed period?

No. Closing the books sets a closing date with one of two security options: a warning, or a warning plus a password. Neither prevents changes outright, and Intuit points you to the Exceptions to Closing Date report to see what changed after you closed. Treat the closing date as a control that records and discourages edits rather than one that blocks them.

Why am I seeing voided Stripe invoices I never voided?

Most likely because someone revised them. Stripe does not allow substantive edits to a finalized invoice, so its documented approach is to create a new invoice and void the old one. When you click Update invoice in Stripe's invoice editor, Stripe finalizes the new invoice and voids the old one automatically. The revision shows in the invoice History section, and it emits the same invoice.voided event a deliberate cancellation would.

What is the difference between a void and a credit memo for closed-period purposes?

A void rewrites an existing document, so it takes effect in the period that document is dated. A credit memo is a separate document with its own date, so it takes effect in the period you issue it. Both bring the receivable to zero. Only one of them reaches backwards.

Can Acodei use a credit memo instead of voiding the QuickBooks invoice?

Yes. Acodei documents a Create Credit Memo on Void toggle that uses a same-day Credit Memo rather than voiding the QuickBooks invoice, specifically to protect closed periods while invoices are voided in Stripe. It is an advanced setting in the Acodei admin panel rather than a self-serve option, so enabling it means contacting support.

What happens if a customer pays an invoice after the credit memo was created?

Acodei documents that the credit memo auto-reverses if the invoice is later paid. Because a credit memo is an ordinary document rather than an edit to an existing one, undoing it is a normal operation, and the reversal lands on the date the payment arrived rather than reaching back into the original period.

Does this apply if I am not using Invoice Sync?

No. Without Invoice Sync there is no QuickBooks invoice for a Stripe void to act on, because sales post as receipts rather than as invoices and payments. The closed-period question described here is specific to the invoice workflow.