Skip to main content

​
Introduction

RO e-Factura is Romania’s mandatory national e-invoicing system, run by the Ministry of Finance and ANAF. Every B2B invoice in scope must be uploaded within 5 working days of issue, and B2C invoices are reported the same way. The platform validates each invoice and seals it with the Ministry of Finance signature: the sealed XML is the legal invoice. Invoices are encoded in UBL 2.1 following CIUS-RO, the Romanian profile of EN 16931. Invopop builds the XML from your GOBL invoice, checks it against the official ANAF schematron, uploads it and waits for ANAF’s decision. This guide covers three key processes:
  • Invoice issuance: Creating and sending CIUS-RO invoices through RO e-Factura
  • Corrections: Credit notes and corrective invoices for accepted invoices
  • Special cases: B2C, self-billed and accounting invoices
For registering parties (suppliers) with RO e-Factura, see the companion guide: Romania: Supplier registration. Invopop supports two use cases that require different configurations:
  • Send only: You issue invoices through RO e-Factura on behalf of your suppliers. This is the simplest setup and does not require the Cron app or the sync and import workflows.
  • Send & receive: In addition to sending, you also want to automatically import invoices received by your suppliers. This requires the Cron app to periodically check for new invoices.
The table below summarizes which components are needed for each use case:

​
Prerequisites

To issue invoices through RO e-Factura, you will need:
  • A registered party (supplier): follow the RO e-Factura supplier registration guide to connect the Romania app and register the party with ANAF before issuing.
  • Customer details, including their Romanian CIF for domestic B2B invoices, and their address with county.
  • Line items with quantities, prices, and applicable VAT rates.

​
Setup

All of the following steps must be carried out from the Invopop Console.
The Romania app must already be connected and the party registered with ANAF — both are covered in the supplier registration guide.
1

Configure the invoice sending workflow

This workflow numbers the invoice, converts it to CIUS-RO XML, signs it, sends it to RO e-Factura and renders a PDF:
  1. Set state to Processing.
  2. Add sequential code gives the invoice its number.
  3. Generate e-Factura XML converts the GOBL invoice to CIUS-RO, checks it against the ANAF schematron and attaches it as efactura.xml.
  4. Sign envelope seals the GOBL document so it can no longer change.
  5. Send e-Factura XML to ANAF uploads the XML and waits until ANAF accepts or rejects it. On acceptance, the official XML returned by ANAF is attached as anaf-efactura.xml and the invoice is stamped with the ANAF upload ID and response date.
  6. Generate PDF renders a PDF of the invoice in Romanian to hand to your customer.
  7. Set state to Sent.
Keep Sign envelope before Send e-Factura XML to ANAF. Invopop stamps the invoice after sending it, and only a signed invoice can be stamped: the send step fails on an unsigned one.
Keep the Workflow ID at hand, you’ll use it later.

Have your agent issue an RO e-Factura invoice in your sandbox.

Open in Cursor

​
Running

In this section, we’ll provide details on how to issue invoices on behalf of a registered party.

​
Send an invoice

Once a party is registered, you can issue invoices on their behalf.
GOBL invoices sent to RO e-Factura must include the ro-efactura-v1 addon in $addons, which applies the CIUS-RO rules on top of EN 16931.
1

Upload an invoice

Use the Create an entry endpoint to upload the invoice details. Include an invoice object in the data field with these required fields:
  • $addons: include ro-efactura-v1
  • supplier: use the details of the party you’ve registered before
  • customer: the Romanian CIF for domestic B2B invoices, and the address with its county in state
You can copy one of the example invoices below as a reference. They are partial GOBL documents you can also paste directly into the Invopop Console, then click Build and Save.
In this example, we’re issuing a standard B2B invoice from a Romanian supplier to another Romanian business customer.Notice:
  • the minimal version in the first tab contains only the essential fields required to create the invoice,
  • the ro-efactura-v1 addon ensures the document is validated using the national CIUS-RO rules (BR-RO) on top of EN 16931,
  • addresses in Romania carry the county as state (ISO 3166-2:RO code, B for Bucharest), and Bucharest addresses use the sector as locality,
  • payment terms are required whenever an amount is due,
  • the built version in the second tab shows the calculated totals and the untdid-document-type extension set to 380, and,
  • make sure to process it with the “RO generate & send” workflow created during setup.
In this example, the supplier issues an invoice to a consumer without a tax ID.Notice:
  • the customer has no tax_id, so Invopop uploads the invoice to ANAF’s B2C endpoint,
  • the built version adds the thirteen zeros CNP (0000000000000) that Romanian law requires for a consumer without an identifier, and,
  • if the consumer gives you their CNP, add it as a CNP identity on the customer instead.
In this example, we’re issuing a credit note (type code 381) to refund part of a previous invoice.Notice:
  • the type field is set to credit-note,
  • the preceding field references the original invoice by series, code and issue_date,
  • quantities and amounts are expressed as positive values, as in every GOBL credit note, and,
  • the built version shows the untdid-document-type extension set to 381.
In this example, we’re issuing a corrective invoice (type code 384) that replaces a previous invoice.Notice:
  • the type field is set to corrective,
  • the preceding field references the original invoice by series, code and issue_date, and,
  • the built version shows the untdid-document-type extension set to 384.
In this example, the customer issues the invoice in the supplier’s name (autofactură, type code 389).Notice:
  • the $tags field includes self-billed,
  • the registered party issuing the invoice is the customer, so the customer’s CIF is the one used to upload it to ANAF,
  • the built version adds the mandatory Autofactură note and sets the untdid-document-type extension to 389, and,
  • Invopop flags the upload as self-billed (autofactura=DA) automatically.
After uploading you’ll see the document in the Invoices section with status Empty.
2

Send the invoice to the RO generate & send workflow

Send the invoice to the workflow using the Create a job endpoint. Use:
  • workflow_id: use the Workflow ID of the RO generate & send workflow we created during setup
  • silo_entry_id: use the Silo Entry ID of the invoice you’ve just uploaded.
From the Console, open the invoice, click Select workflow, choose RO generate & send and click Run workflow.The job waits on the Send e-Factura XML to ANAF step until ANAF decides, which usually takes a few minutes:
  • ✓ Accepted (ok): the invoice moves to Sent and carries the official XML returned by ANAF, next to the generated XML and the PDF. The invoice is stamped with the ANAF upload ID (ro-anaf-upload-index) and the date ANAF returned (ro-anaf-upload-date), shown in the Headers section of the invoice in the Console.
  • × Rejected (nok): the job fails with the errors ANAF returned. Correct the invoice and run the workflow again.
Invoice in Sent state with the generated and the official ANAF XML
Once ANAF decides, download the official archive it signed with Fetch sent archive. It holds the accepted invoice, or the errors of a rejection.

​
Issue a credit note

An invoice accepted by RO e-Factura cannot be cancelled. To correct it, issue a new document that references it. In Romania you can either:
  • Issue a credit note (type code 381), which adjusts the value of the original invoice, or
  • Issue a corrective invoice (type code 384), which replaces the original invoice entirely.
For example, if you issued an invoice for 100 lei but later realized it should have been 80 lei, you can either issue a credit note for 20 lei, or a corrective invoice for 80 lei. Unless you have a specific requirement to replace the original invoice, we recommend only using credit notes. They’re more widely supported across countries, while corrective invoices are specific to a few jurisdictions like Romania.
1

Upload a credit note

A credit note in Invopop is an invoice of the type credit-note. The process is very similar to uploading an invoice, use the Create an entry endpoint to upload a credit note. Include an invoice object in the data field, with these required fields:
  • $addons: include ro-efactura-v1
  • supplier: use the same supplier details as in the original invoice
  • type: credit-note
  • preceding: references the original invoice, within it, you must include:
    • uuid: the UUID of the original invoice (optional but recommended)
    • issue_date: the date of the original invoice
    • series: the series of the original invoice
    • code: the code of the original invoice
As with every GOBL credit note, quantities and amounts are expressed as positive values. You can copy the B2B credit note example above as a reference.After successful upload, you’ll see the credit note in the Invoices section with status Empty. If you’ve included the uuid of the invoice in preceding, you’ll see a link to the credit note in the Related tab of the original invoice.
2

Send the credit note to the RO generate & send workflow

Send the credit note to the same workflow using the Create a job endpoint. Use:
  • workflow_id: use the Workflow ID of the RO generate & send workflow we created during setup
  • silo_entry_id: use the Silo Entry ID of the credit note you’ve just uploaded.
The credit note moves to Sent once ANAF accepts it.

​
Issue a corrective invoice

1

Upload a corrective invoice

A corrective invoice in Invopop is an invoice of the type corrective. The process is very similar to uploading an invoice, use the Create an entry endpoint to upload a corrective invoice. Include an invoice object in the data field, with these required fields:
  • $addons: include ro-efactura-v1
  • supplier: use the same supplier details as in the original invoice
  • type: corrective
  • preceding: references the original invoice, within it, you must include:
    • uuid: the UUID of the original invoice (optional but recommended)
    • issue_date: the date of the original invoice
    • series: the series of the original invoice
    • code: the code of the original invoice
The corrective invoice carries the full, corrected content of the original. You can copy the B2B corrective invoice example above as a reference.After successful upload, you’ll see the corrective invoice in the Invoices section with status Empty. If you’ve included the uuid of the invoice in preceding, you’ll see a link to the corrective invoice in the Related tab of the original invoice.
2

Send the corrective invoice to the RO generate & send workflow

Send the corrective invoice to the same workflow using the Create a job endpoint. Use:
  • workflow_id: use the Workflow ID of the RO generate & send workflow we created during setup
  • silo_entry_id: use the Silo Entry ID of the corrective invoice you’ve just uploaded.
The corrective invoice moves to Sent once ANAF accepts it.

​
Special cases

Invopop picks the right ANAF upload options from the invoice itself, so the same workflow handles every case:
  • B2C invoices: when the customer has no tax ID, the invoice is uploaded to ANAF’s B2C endpoint. The ro-efactura-v1 addon adds the thirteen zeros CNP that Romanian law requires for consumers without an identifier.
  • Self-billed invoices (autofactură, type code 389): add the self-billed tag. The customer issues the invoice in the supplier’s name, so the customer must be the registered party. The addon adds the Autofactură note, and the upload is flagged as self-billed.
  • Invoices for accounting purposes (type code 751): add the accounting tag.
  • Enforcement procedures: add the enforcement tag and name the enforcement body as payee. The upload is made with the payee’s CIF and flagged as enforcement.

​
GOBL addon reference

Detailed information about the CIUS-RO rules, scenarios and tags can be found in the ro-efactura-v1 addon documentation.

​
FAQ

UBL 2.1 in the Romanian profile of EN 16931, called CIUS-RO (version 1.0.1). RO e-Factura also accepts CII (D16B). The platform checks the invoice against the EN 16931 rules and the national BR-RO rules.
No. The legal invoice is the XML file that the Ministry of Finance seals after validation. A PDF has no legal value, but you can give one to your customer as a readable copy.
You cannot cancel a sealed invoice. Issue a credit note (type 381) or a corrective invoice (type 384) that references the original invoice.
No. The platform statuses show only whether the invoice passed validation. The buyer settles a dispute directly with the supplier, and the supplier corrects the invoice with a new document.
Since 1 August 2025, the standard rate is 21% and the reduced rate is 11%. If an invoice is in another currency, the VAT amounts must also show in RON.
For 60 days. After that, ANAF archives the files, and a copy is available only on request. Keep your own copy of each sealed invoice.
Yes. The buyer issues the invoice in the supplier’s name, with type code 389.
Invoices that declare the ro-efactura-v1 addon: standard invoices (380), invoices for accounting purposes (751, with the accounting tag), self-billed invoices (389, with the self-billed tag), credit notes (381) and corrective invoices (384).
Usually a few minutes. After the upload, the Send e-Factura XML to ANAF step waits and checks the upload status until ANAF answers ok or nok. The job finishes when ANAF has decided.
When ANAF accepts the invoice, Invopop attaches the official XML returned by ANAF to the invoice entry as anaf-efactura.xml, next to the generated efactura.xml. The archive is also kept in Invopop’s database.
The job fails with the errors ANAF returned. Correct the invoice and run the workflow again; a rejected invoice can be sent again.
No. Invopop never uploads an accepted invoice twice. To change an accepted invoice, issue a credit note or a corrective invoice that references it.
Invopop picks the ANAF upload options from the invoice itself. An invoice to a customer without a tax ID goes to the B2C endpoint, and a self-billed invoice is uploaded with the customer’s CIF and flagged as autofactura. No workflow configuration is needed.
More available in our Romania FAQ section

Participate in our community

Ask and answer questions about invoicing in Romania →