Romania
B2G, B2B, B2C, Outbound, Tax Reporting
2026-08-28
RO e-Factura implementation needs controlled structured data and response handling, not only a file upload step.
How to use this guide
A useful project outcome is not a document that merely repeats the rule. It is a traceable decision model that connects the rule to legal entities, transaction scenarios, source data, system behaviour, operating ownership and evidence.
End-to-end operating flow
A platform call is one stage inside a longer business lifecycle.
- Qualify
Determine scope, channel and document path before building the payload. - Validate
Block incomplete identities, tax facts, amounts and references before transmission. - Generate
Create the platform-specific representation with a traceable mapping version. - Submit
Use idempotency and a correlation key so retries do not silently duplicate documents. - Interpret
Convert every response into a finance-readable status and responsible action. - Deliver and reconcile
Coordinate customer delivery with the validated or reported result and ledger posting. - Retain
Archive source, payload, response, representation and later events as one evidence chain.
Country-specific decisions
01
Generate from checked invoice facts
Supplier and buyer identifiers, tax details, lines, totals, dates and references should be validated before producing the Romanian structured invoice representation.
02
Control submission time
The five-working-day deadline requires a timestamped queue, visible pending status and escalation before the legal limit. A technical retry must not silently reset the business deadline.
03
Keep platform responses
Submission identifiers, validation messages, accepted payloads and corrections should be linked to the source invoice for support, reconciliation and audit.
Treat every artifact as a separate controlled object
The commercial invoice, transmitted payload, authority response and customer document may be related, but they are not interchangeable. Their distinct identities must remain visible in monitoring, reconciliation and audit retrieval.
| Decision area | What must be decided | Evidence to retain |
|---|---|---|
| Source transaction | Identify the authoritative ERP document and the event that makes it eligible for processing. | Document key, version, company, timestamps and source status. |
| Structured payload | Generate the required national or platform representation from validated facts. | Payload version, mapping version, checksum and submission correlation ID. |
| Platform response | Interpret technical and business responses without collapsing them into one success flag. | Raw response, normalized status, reason and next action. |
| Customer representation | Deliver the legally and commercially appropriate readable document through the agreed channel. | Delivered document, recipient, channel and delivery time. |
| Adjustment chain | Link replacement, cancellation, credit/debit or other follow-on documents to the original identity. | Original reference, event history and final reconciled status. |
Failure scenarios the design must handle
- Validation rejection after the ERP invoice has already been posted.
- Network timeout where the platform may have accepted the document but the sender did not receive the response.
- Duplicate submission with a different technical message ID but the same business invoice.
- Authority acceptance without successful customer delivery or finance reconciliation.
- A later correction that breaks the link to the original submitted and delivered artifacts.
Official sources
- Romanian legislative portal — OUG 69/2024
- ANAF current guides and RO e-Factura material
- ANAF clarification on B2B and B2C simplified invoices
- ANAF 2026 RO e-Factura changes and five-working-day deadline
- ANAF clarification on B2C customer delivery