MRA e-invoicing: what actually changes at your counter
Most businesses first meet MRA e-invoicing as a deadline in a circular. That framing is misleading, and it costs people money. E-invoicing is not a return you file at the end of the month. It changes the transaction itself, at the counter, while the customer is standing there.
The invoice stops being yours alone
Under the Electronic Billing System, an invoice is not final when your system prints it. It is transmitted to the MRA, validated, and comes back with an IRN and a QR code. Only then is it a compliant fiscal document. The receipt your customer walks out with has to carry that QR code.
That single fact is what makes this an operations problem rather than an accounting one. Three things follow from it:
Your till needs to be online at the moment of sale. Not at close of business. If the connection drops mid-afternoon, you need to know what your system does: queue and transmit later, or stop selling. Both are valid answers. Not having decided is not.
Someone owns the failures. Transmissions get rejected. A wrong BRN, a tax code that does not map, a customer record missing a field. If nobody is watching a queue, you find out weeks later with a pile of invoices that were never valid.
Credit notes and returns follow the same path. A refund is not a local correction any more. It is its own transmitted document referencing the original IRN.
What we see going wrong
The pattern is almost always the same, and it is rarely the software. It is the data underneath it.
Customer records without a BRN or a VAT number, because nobody needed one before. Product lines carrying a tax rate that was set up years ago and quietly wrong. Two customer records for the same company, one of which has the correct details. None of this matters when you are printing your own invoices. All of it matters the moment a third party validates them.
So the real work in an e-invoicing project is not the connector. It is the week spent cleaning master data before the connector is switched on.
A sensible order of work
- Audit your data first. Every customer you invoice, every product, every tax code. Find the gaps while they are cheap.
- Map your tax codes to MRA categories explicitly. Do not assume the default mapping is right for your trade.
- Run in parallel. Transmit, but keep printing the way you do today, until the rejection rate is at zero for a full week.
- Decide the offline rule before you go live, and tell the counter staff what it is.
- Give the rejection queue an owner and a time of day they look at it.
Where this sits with a POS
If you are selling over a counter, the QR code has to reach the customer’s receipt, which means your POS and your e-invoicing path cannot be two separate systems that reconcile later. This is the main reason we supply Sunmi terminals with Odoo POS and the MauCAS QR flow already configured. Not because the hardware is special, but because the integration is the part that goes wrong.
If you are working through this and want a second pair of eyes on your data before you commit to a go-live date, book a call. We do this often enough to know where the gaps usually are.