Guides

Magento and e-Factura: The Compliance Guide for Romanian Merchants

October 16, 2026 - Alexandru-Manuel Carabus

e-Factura is mandatory for any Magento store selling in Romania, and enforcement is tightening. Here is what the SPV system requires, the deadlines that already passed, and what it actually takes to make a Magento store issue compliant invoices.

If you run a Magento store that sells in Romania, e-Factura is not a feature you might add someday. It is a legal requirement you are already inside. Romania's national electronic invoicing system has been mandatory for business-to-business sales since July 2024 and for business-to-consumer sales since January 2025, and the enforcement is tightening, not loosening. This is a practical guide to what the system requires, the deadlines that matter, and what it actually takes to make a Magento store issue compliant invoices. It is not tax advice, so confirm the specifics for your business with your accountant.

What e-Factura actually is

RO e-Factura is the mandatory national e-invoicing system operated through ANAF's SPV platform (the Virtual Private Space). Instead of a PDF you email to a customer, every invoice has to be generated as a structured XML file in the RO_CIUS format (Romania's national standard, built on the UBL 2.1 syntax and compliant with the European EN 16931 norm), uploaded to SPV, validated by the system, and sealed by the Ministry of Finance. The important shift for merchants: the PDF is no longer the legal invoice. The validated XML sitting in SPV is. If it is not in SPV, from the tax authority's point of view it was never issued.

The deadlines, in order

The timeline is worth having straight. Domestic B2B e-invoicing became mandatory for Romanian-established taxpayers on 1 July 2024. B2C followed on 1 January 2025, after a voluntary phase. From 1 January 2026, invoices generally have to be transmitted to SPV within five working days of issue, so the old habit of batching them up at month-end no longer works. During 2026 the net widened further: ANAF Order 378/2026 pulled associations, foundations, non-profits, individual farmers, and sole traders into the register from 1 June 2026, and smaller businesses under 500,000 euro in annual turnover were given runway to 1 July 2026 for full enforcement. The direction is one-way. If you sell online in Romania, you are in scope now.

What this means for a Magento store specifically

Your store already generates invoices. What e-Factura adds is that each one has to become valid RO_CIUS XML, reach SPV inside the deadline, and have the returned identifier stored back against the order so you have proof it was accepted. There are three common ways to make that happen. The first is a Magento e-Factura extension that builds the XML and talks to the SPV API directly over OAuth. The second is pushing order and invoice data into accounting or ERP software that already handles the SPV side (the SAGA, SmartBill, Oblio, and FGO family of tools). The third, for complex catalogs or heavy B2B, is a custom integration built to your exact invoicing flow. Which one is right depends on your volume, your accounting setup, and how much of your invoicing logic already lives in Magento versus your ERP.

Whichever route you take, the same catch decides whether it works: SPV rejects malformed XML, strictly. The usual failure points are a missing or invalid CUI or CIF on a B2B order, VAT rates that do not map cleanly to the RO_CIUS code list, missing unit-of-measure codes, rounding that disagrees by a bani, and product lines that do not validate against the schema. A store that has been casual about tax classes, customer tax IDs, and product data will start getting rejections the day the integration goes live. Clean master data is not a nice-to-have here, it is half the actual work.

The parts people underestimate

The initial sale is the easy case. Credit notes and storno invoices, partial refunds, and returns all have to flow through e-Factura too, and those paths are where hurried integrations break. B2B adds its own requirement: the buyer's CUI has to be captured correctly at checkout, because you cannot issue a valid B2B e-invoice without it. Multi-warehouse and marketplace setups complicate which legal entity issues the invoice. And the OAuth token your store uses to authenticate to SPV expires on a schedule and has to be refreshed; when nobody owns that, invoices silently stop transmitting and you find out when a customer or an auditor asks.

This is why e-Factura belongs in maintenance, not in a one-and-done project. ANAF updates the schema, the validation rules, and the deadlines regularly, and a rejected invoice is both a compliance exposure and a cash-flow problem, because a customer who cannot get a valid invoice may not pay. The same maintenance discipline that keeps a store patched and fast is what keeps its invoicing compliant through the next schema change. We wrote about that cadence in The Complete Magento Maintenance Guide.

How LIQUIDLAB approaches it

We build and maintain the SPV integration as part of the store rather than bolting it on: the XML generation, the OAuth connection to e-Factura, the storno and refund paths, and the monitoring that catches a schema change or an expired token before it turns into a stack of rejected invoices. Just as important, we clean the tax and product master data first, because that is what decides whether the XML validates at all. As a Romanian agency that builds and takes over Magento stores for local merchants, this is home ground for us, the same ground we covered on the language side in the Romanian language pack piece and on the frontend in Hyva in Romania.

If your e-Factura flow today is a manual export, a fragile script nobody wants to touch, or something that has quietly started throwing rejections, book a free strategy call with LIQUIDLAB. We will look at how invoices leave your store, where they are failing SPV validation, and what it would take to make the whole path reliable, so compliance stops being a monthly fire drill.