A Cancellation Your Customer Can Refuse
Everywhere else, voiding a document is something you do. Here it is something you ask for — and your customer can say no, or say nothing, which is worse.
Cancelling a document is the most unremarkable operation in accounting software. Somebody raised the wrong invoice, you void it, the ledger reverses, and the audit trail records who did it and when. It is unilateral, immediate and certain. Every system models it that way because everywhere it works that way.
In Mexico a cancellation is a request your customer can decline. It is not an act you perform on your own record; it is an approach to a counterparty, with an outcome you do not control. And once a year has closed, the request is no longer available at all.
Those are two properties, and between them they break an assumption that runs through most finance schemas: that the reversal of a document is always possible and always yours.
The state nobody models
Ask a system what states an invoice can be in and you will get some version of: draft, issued, paid, void. Four states, all of them yours to move between.
This market needs a fifth: cancellation requested, outcome unknown. Not void — the document still stands. Not issued in the ordinary sense either, because you have asked for it to stop existing. It is a real position, it can persist, and it can end in a refusal that leaves the original in force.
| State | Who controls it | Modelled by most systems |
|---|---|---|
| Draft | You | Yes |
| Issued | You | Yes |
| Paid | Your customer, effectively | Yes |
| Cancellation requested | Your customer | No |
| Cancelled | Your customer, by agreeing | Modelled as though it were yours |
| Refused, original stands | Your customer | No — and there is nowhere to record why |
Silence is the hard case. A refusal is at least an answer; a request nobody responds to leaves a document in a state your system has no word for, indefinitely.
Why the deadline is the more dangerous half
The consent requirement is awkward and visible — somebody has to chase a customer, and everybody knows it.
The deadline is neither. A reversal that is available today and not available after a period closes turns an ordinary correction into a dated one, and the date arrives without announcement. An error found in the wrong week is not more expensive to fix; it is impossible to fix by the route everybody assumes. Whatever happens instead is a different transaction with different consequences — and that is a conversation with an adviser rather than a keystroke.
There is no procedure in this post, and no timeframe
We do not maintain cancellation procedure for this market and we do not issue the documents in the first place, so we are not the source for how a request is made, what reasons are acceptable, or exactly when the door closes. What is safely ours is the observation that a reversal requiring consent and carrying a deadline is a state machine most software does not have — and that is a software problem worth naming.
What follows for anybody choosing a system here
Since the document itself is cleared by a certified provider rather than by your operations system, the practical question is not whether your operations system can cancel. It is whether the two systems can agree about what happened.
-
Where does the pending state live?
If the invoicing product knows a cancellation is pending and your operations system does not, then for as long as the request is open the two disagree about your revenue. Somebody has to hold that state, and it is better decided than discovered.
-
What happens on a refusal?
The original stands. Does anything in your process turn that outcome into a record, or does it live in the memory of whoever chased the customer? A refusal is a commercially significant event and it is the one most likely to go unrecorded.
-
Who is watching the deadline?
If the answer is nobody, then the routine correction path is silently time-limited and the first anyone learns of it is when it fails. This is a diary and a named person, not a feature — and being explicit that it is manual is what stops it being assumed.
Our position, and it is narrow
A full audit trail of who changed what and when
Which is the part that helps here: whatever your process decides, the record of it exists and is attributable rather than remembered.
Documents held against the transaction they justify
So the correspondence and evidence around a correction sit with the transaction rather than in an inbox.
A pending-consent state on a document
Not built. Our documents move between states you control, because that is true of every other market we serve. Modelling a state whose owner is your counterparty is ordinary work and commissionable with a written specification, a timeline and a price.
A credit note carrying a tax split
Not built either, and relevant here for the same reason it is relevant in Fiji: our credit note holds one amount, a customer, a reason and an optional link. Where the reversal route is constrained, the alternative document matters more, not less.
Issuing or cancelling anything with the authority
Not ours in any version. We do not issue, so we do not cancel. The clearance belongs to a certified provider and the market page says so in its first line.
The general lesson is worth more than the market: whenever a reversal needs somebody else's agreement, your system needs a state for waiting. Approval-to-return, warranty acceptance, a customer confirming a delivery — the shape recurs, and the usual workaround is a spreadsheet of things somebody is chasing. That works until the person chasing goes on leave.
What is built here, what is not, and what we would decline is on the Mexico market page. The item-record version of this market's pressure is a catalogue is not a text field, and the counterparty-record version is fields that are not on your customer record.
