CFDI cancellation needs request-to-status reconciliation
Mexico's SAT describes cancellation as a workflow with a reason code, a replacement folio when applicable, a receiver-response path in some cases, and a resulting invoice status. Tax and finance teams should preserve those events as a linked record instead of treating a submitted request or an ERP void as final cancellation.
Editorial figure by Indirect Tax Monitor. Source context: Mexico SAT CFDI cancellation process.
Treat cancellation as a stateful authority workflow
The direct control answer is to keep the original CFDI, the cancellation request, every response event, and the final status as separate linked records. SAT's official process page says an issuer may send a cancellation request through the SAT portal or through a certification provider. That request is an action, not evidence by itself that the invoice is already cancelled. An ERP void, credit workflow, provider acknowledgment, receiver notification, receiver response, and SAT status observation describe different events and should retain different timestamps and evidence.
For each request, preserve the issuer RFC, receiver RFC, original UUID, original issue timestamp, invoice type and amount, current observed status, request timestamp and channel, requested reason code, submitting identity, certification-provider transaction identifier when one exists, raw response, and the later SAT status check. Keep the accounting action and commercial correction beside this authority trail rather than overwriting it. A reviewer should be able to answer which document was targeted, why, through which route, what the authority or provider returned, and whether the official state subsequently changed.
Bind the reason code to any replacement invoice
SAT lists four cancellation reasons: an issued document with related errors, an issued document with errors but no relation, an operation that did not occur, and a named operation related to a global invoice. The code is therefore part of the evidence, not a generic free-text label. Store the selected code, the business event that supports it, the person or governed rule that selected it, and any later correction. Do not translate all four paths into one cancelled reason inside the billing system.
When reason 01 is used, SAT says the request must identify the fiscal folio of the replacement CFDI. Preserve that relationship in both directions: the original UUID points to the replacement UUID, and the replacement points back to the original. Then reconcile the two documents' issuer, receiver, currency, tax components, commercial reference, accounting treatment, and periods. A replacement link does not by itself establish that every value is correct, that the recipient received the new document, or that reporting and ledger consequences were completed.
Separate receiver response from final invoice status
The SAT page describes two broad routes. Where receiver acceptance is required, the receiver receives a tax-mailbox notice and has three business days from receipt of the request to accept or reject it; the page describes a non-response within that period as acceptance. It also lists cases where receiver acceptance is not required and says cancellation is immediate. A workflow should record which route it applied, the rule or evidence supporting that classification, the notification time where relevant, the response deadline, any receiver decision, and the status later observed from SAT.
Do not infer the route from invoice amount or type without checking the current official rule and the facts of the document. Keep local time, business-day calendar, first and later request attempts, and notice evidence explicit. A provider's accepted API call is not the receiver's acceptance, and receiver acceptance is not a substitute for retrieving the resulting invoice status. If systems use labels such as requested, pending, accepted, rejected, cancelled, not cancellable, or expired, map each label to the source event that supports it and retain the unmapped raw authority or provider value.
Test retries, substitutions, and period boundaries
A useful test set should include one request that needs receiver acceptance, one that follows a documented no-acceptance route, one rejected request, one unanswered request, one reason-01 replacement pair, one reason-02 correction without a related folio, a repeated request, and a request initiated near a reporting-period boundary. For every case, retrieve the original XML and UUID, request payload, transport response, notification or exemption evidence, receiver event when applicable, final SAT status observation, replacement document, accounting entries, and the population used for tax reporting.
Run the test when the portal or certification-provider response is delayed and when SAT and the source ERP temporarily disagree. The process should queue an exception with an owner and next verification time rather than promote the most convenient state. Reconcile counts and amounts by legal entity, period, reason, status, and replacement relationship. Preserve subsequent status observations without erasing the state that tax and finance reviewers relied on at close or filing time.
Indirect Tax Monitor reviewed SAT's exact cancellation-process page on September 24, 2026. The page supports the workflow facts above but does not carry an attributable publication date, so this is durable operating analysis rather than a claimed post-cutoff development. The source does not establish a reader's cancellation eligibility, the current application of every exception, the accuracy of any reason code, a recipient's response, final SAT status, tax treatment, accounting entry, filing effect, penalty exposure, or compliance outcome.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Indirect Tax Monitor will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.