Magento · 14 August 2026 · 12 min read
Romanian e-invoicing in Magento 2: what the law wants, and what actually breaks
Mandatory since 1 January 2025, with a five-working-day deadline. The hard part isn't the law — it's the nine places in Magento where the implementation gives way.
If you sell into Romania, e-Factura is not optional and it is not a checkbox. Almost every article about it explains the law. Those are useful for an accountant and useless for whoever has to make it work in a store doing thousands of orders a month. This one is about the second part: what actually happens when you connect a Magento 2 to the Romanian tax portal, and why “we installed a module” doesn't mean you're compliant.
What the law requires, briefly
The framework was built in four stages: OUG 120/2021 introduced the system for dealings with public institutions, OUG 115/2023 made B2B mandatory, OUG 28/2024 brought the penalties and clarified the deadline, and OUG 69/2024 extended the obligation to B2C.
- Since when: B2C has been mandatory since 1 January 2025 for operators established in Romania, where the supply takes place in Romania for VAT purposes.
- Within what deadline: the XML has to reach the tax portal within a maximum of five working days from issuing the invoice. The deadline is unified — the same for B2B and B2C.
- What happens if you don't: the fines in OUG 28/2024 apply per untransmitted invoice — 5,000–10,000 lei for large taxpayers, 2,500–5,000 for medium ones, 1,000–2,500 for the rest.
Note the part that matters for architecture: per untransmitted invoice. In a store doing 3,000 orders a month, an integration that fails silently on 2% of invoices means 60 invoices a month. The risk isn't theoretical, it's multiplicative.
Why it isn't “just a module”
Magento has an object called invoice. The name misleads: it's an internal management document marking that an order has been invoiced. It is not a Romanian fiscal invoice. It has no series and number from a fiscal register, it doesn't have the structure required by the CIUS-RO standard, and it doesn't necessarily contain every field the tax authority validates.
An e-invoicing module translates between the two. How well it does that only shows in the edge cases — and real stores live in the edge cases.
The nine places implementations give way
1. The moment of issue, which starts the clock
The five working days run from the invoice being issued. In a store, “issued” could be at order placement, at payment, at dispatch or at delivery — and every Magento configuration does something different. If the invoice generates automatically at placement but the order is cancelled the next day, you've issued a document you now have to credit. If it generates at dispatch, the clock starts later, but you have overdue invoices whenever the warehouse runs behind.
2. Partial invoices
Magento allows several invoices against the same order — normal, when you ship in batches. Each is a separate fiscal document with its own deadline. Integrations built in a hurry transmit only the first.
3. Credits and returns
A Magento credit memo corresponds to a credit note, which also goes to the portal. In a store with frequent returns — fashion, footwear — that's a significant share of volume, not an exception.
4. VAT rates and category codes
The standard wants fiscal category codes, not just a percentage. Reduced rates, exemptions, reverse charge and intra-community supplies each have their own code. Magento's tax configuration almost never maps one to one, and the discrepancy appears as a validation error only after transmission.
5. Customer data
For B2B you need a valid, verified VAT number. For B2C the structure is different and you shouldn't send data you aren't obliged to transmit. Addresses need country and county codes in the standard's format, not the free text a customer types at checkout.
6. What happens when the portal rejects
A rejected transmission is not a transmission. You need a retry queue, with a bounded number of attempts and with visibility: somebody has to be able to see, on one screen, which invoices failed and why. A fire-and-forget integration leaves you fines you discover months later.
7. Double submission
Retrying without idempotency produces duplicates. There has to be a stable key on the invoice and a check before every send, otherwise a cron that runs twice transmits the same document twice.
8. Archiving the signed document
The document with legal force is the one signed by the tax authority and returned from the portal, not the XML you sent. It has to be downloaded, attached to the order and retained. Plenty of integrations transmit correctly and download nothing back.
9. The cron that isn't running
All the mechanics above depend on cron. Magento's cron stops more often than people think — after a deploy, after an upgrade, when the queue jams on one job. Without monitoring on the age of the oldest untransmitted invoice, you find out it stopped from the fine.
How to vet a module before buying it
The questions below separate serious modules from ones that merely generate XML. They're the same questions we ask when evaluating one for a client:
| Question | What you want to hear |
|---|---|
| How does it handle partial invoices? | Each invoice transmitted separately, with its own deadline |
| What does it do with credit notes? | Transmits them automatically, linked to the original invoice |
| What happens on rejection? | Bounded retry, plus a screen showing the errors and the reason |
| Does it download the signed document? | Yes, and attaches it to the order |
| How does it prevent duplicates? | An idempotency key on the invoice, checked before sending |
| How are VAT rates mapped? | Configurable, on fiscal category codes, not hardcoded |
| Is there alerting? | Yes, on the age of the oldest untransmitted invoice |
If the answer to three of them is vague, the module solves the demo and leaves you the problem.
What we do, concretely
We don't sell a module of our own. We pick a suitable one, configure it around the store's real flow, and add what's missing — usually the monitoring and the error handling. The review is part of the code audit, and the monthly supervision part of the maintenance retainer, alongside security patches.
One detail that gets ignored: this integration touches checkout and orders, exactly the areas a Magento upgrade can break. If you're on an out-of-support version, fix the version first — otherwise you're building on a foundation that has to be replaced anyway.