The order was cancelled after the invoice went out

The invoice went out on Tuesday. On Thursday the customer cancelled. By then the invoice had been emailed, recorded, counted in the month, picked up by the bookkeeping sync, and included in the figure you quoted to somebody on Wednesday.

The instinct is to delete it and pretend the two days did not happen. Every accounting system will stop you, and they are right to. What follows is a series of small decisions about how the cancellation gets recorded, and each one determines whether your systems still agree with each other next month.

You cannot unsend paperwork, so systems correct rather than erase

The rule that governs all of this: financial systems record corrections as new entries rather than by editing old ones. An invoice that existed has to keep existing, and its reversal is a separate document pointing at it.

Stripe is explicit about the distinction. Its documentation on credit notes says "the difference between issuing a credit note and adjusting the amount of an invoice by revising it is that a credit note doesn't void and replace the original invoice." One approach leaves a trail of two documents; the other replaces the first.

This is not bureaucracy for its own sake. The customer has a copy of what you sent. If your records show something different from their records, the difference will be discovered at the worst moment — during a payment dispute, an audit, or a conversation about whether they already paid.

The status that says paid when nothing was paid

Here is the detail worth the whole article, because automation walks straight into it.

Stripe documents that "a credit note reduces the amount due without recording any payment. However, if a credit note reduces the balance of an open invoice to 0, the invoice status changes to paid."

Read that again. Cancel an unpaid invoice properly, with a full credit note, and the invoice ends up marked paid — with no money having moved.

Now think about everything downstream that keys off that word. A workflow that sends a receipt when an invoice becomes paid. A dashboard that sums paid invoices for the month. A commission calculation. A chase sequence that stops when an invoice is paid, which is at least a case of the right thing happening for the wrong reason. Anything watching for paid as a proxy for "money arrived" will count a cancellation as revenue.

Nothing here is broken. The status field means "there is nothing left owed on this invoice", which is true. It just does not mean what almost everyone building on top of it assumes it means.

There is a second edge on the same page: a credit note can be voided only while the invoice is open. Once the invoice is paid, the credit note cannot be reversed. So the correction you make in a hurry on Thursday afternoon is, in some states, not undoable.

Why last month's report will not change

The other half of the divergence is timing, and it is where two systems that are both correct stop matching.

Shopify's documentation on sales reports says reversals — its umbrella term covering refunds, returns, edits and cancellations — "display as a negative value for the day that they were processed." Not the day of the sale. The day somebody clicked the button.

Sales reports also include "open, archived, pending, and canceled orders", with only deleted and test orders left out. So a cancelled order does not vanish from the sales figure; it stays, and a negative entry appears later to offset it.

This produces a report that is right and looks wrong. March shows the sale. April shows the reversal. March's total never changes, so a number you quoted in early April was true when you said it and is still sitting in the report. If your accounting system instead books the correction back to the original month — and plenty do, because that is what matching revenue to its period means — then the two will disagree by design, every single month, for every cancellation that crosses a month boundary.

Small businesses discover this while trying to work out who made the mistake. Nobody did. The systems answer different questions: one reports activity by day, the other reports the economics of a period.

Cancelled and refunded are not the same event

The word "cancel" covers several situations, and the systems distinguish them even when the conversation does not.

Nothing shipped and no money taken. The order stops, the authorisation is released. This is the cheapest case and the one most likely to be handled cleanly everywhere.

Money taken, nothing shipped. Now there is a payment to reverse, and the reversal has its own date, its own fee treatment, and its own line in the reports.

Shipped, then returned. Two physical events and two financial ones, usually days apart, with the stock movement and the money movement recorded separately.

Partially cancelled. One line of five. This is where automation most often produces something wrong rather than something incomplete, because a rule written for whole orders has to decide what to do with a fraction of one.

Before asking what your automation does, be clear which of these you actually have. A workflow that handles the first case elegantly can make an expensive mess of the fourth.

What to check in your own setup

Find everything that watches for "paid". List every automation, report and notification keyed to that status, then ask each one whether a zeroed invoice should count. Most were written when "paid" and "money arrived" were the same thing.

Send yourself a cancellation. Issue a small real invoice, cancel it the way you normally would, and follow it everywhere: the customer's inbox, the accounting system, the sales report, the dashboard. Do it once and you will know your own answer to every question in this article.

Ask where the correction lands in time. For each system, is the reversal dated to the original sale or to the day it was processed? Write the answers down; this is the source of most month-end arguments.

Decide who is allowed to cancel. In many small businesses the answer is "whoever is talking to the customer", which is fine as long as the same person knows they are creating a document rather than deleting one.

When this stops being a settings question

For a business with one invoicing tool and a bookkeeper who reconciles monthly, the checks above cover it.

It stops being that when the cancellation has to propagate: the invoice, the stock, the schedule, the commission, the customer's account balance, the report somebody is about to send. Each of those has its own idea of what a cancellation means and its own date for when it happened. The failure is rarely that one system got it wrong — it is that nobody decided which system's answer wins when they differ.

Deciding that, and making the rest follow, is a build rather than a checkbox. Working out which of the two you need is what a process audit settles: $299, three business days, and a straight answer on whether your cancellations need a rule or a rewrite.

Sources

I read these pages in August 2026. Vendor documentation moves; check the vendor's own page before acting on it.

What a credit note does to the original invoice, and the status change that follows a full credit: Stripe on issuing credit notes.

Which orders appear in sales reports and when a reversal is dated: Shopify on sales reports.

Related: the orders your sales report does not know you made covers the opposite case — a sale that never reached the report at all, rather than one that reached it and stopped being true.