eliDocs
/
Country Guides

Romania

Romanian B2B/B2G e-invoicing with Beliq, Peppol BIS UBL with the RO_CIUS Schematron overlay, and the ANAF e-Factura submission boundary.

Romania’s e-invoicing mandate is already live: B2G invoices have been mandatory since 2022, and the B2B mandate took effect 2024-07-01. The format is Peppol BIS Billing 3.0 UBL with the Romanian national CIUS overlay (RO_CIUS / CIUS-RO 1.0.9), governed by ANAF (Agenția Națională de Administrare Fiscală) via the Ministry of Finance. Authority publication lives at mfinante.gov.ro. The base format is the same Peppol BIS Billing 3.0 UBL used cross-border (see the Peppol BIS format reference); the CIUS-RO overlay layers Romania-specific Schematron rules on top.

Romania is a clearance-model market, so Beliq does not count it among its pinned, authority-verified live-coverage countries. The engine can still emit and validate RO_CIUS UBL, as described below, but treat that as a document-layer capability rather than verified coverage: ANAF publishes no set of known-bad examples to test against, so validation is best-effort against the published rules, not a certified guarantee.

Where Beliq fits

  • Generate Romanian invoices via standard: "peppol-bis" with profile: "romania-ro-cius". The builder emits the current CIUS-RO:1.0.1 URN on cbc:CustomizationID and supports the Romania-relevant generic UBL fields: cbc:CountrySubentity (BT-39; ISO 3166-2:RO subdivisions including SECTOR1..SECTOR6 for Bucharest) and cbc:TaxCurrencyCode + a second cac:TaxTotal block (BT-111; BR-RO-030 / BR-53 cross-border invoices in EUR with VAT accounting restated in RON).
  • Validate and parse Romanian UBL against the dual-XSLT Schematron arm vendored from the Helger phive-rules-cius-ro 4.3.5 JAR (Maven Central, Apache-2.0; packages ANAF’s authoritative XSLT). Both URN families are detected: current urn:efactura.mfinante.ro:CIUS-RO:1.0.1 and legacy urn:efactura.mfinante.ro:RO_CIUS:1.0.0.2021. Errors carry BR-RO-* rule IDs from either the CIUS-RO or the RO e-Factura XSLT.

What Beliq does NOT do (ANAF e-Factura boundary)

Romania’s submission network is ANAF e-Factura via the SPV portal. Beliq is not an ANAF-immatriculée e-Factura intermediary. It does not:

  • Submit invoices to ANAF (webservicesp.anaf.ro or its test sibling).
  • Authenticate against ANAF web services with the ANAF-issued client certificate.
  • Apply XAdES signatures to the UBL envelope.
  • Poll for or decode the ANAF-signed receipt (mesaj UBL) acknowledgements.
  • Hold long-term storage that satisfies the “sistemul național de facturare electronică” retention obligation.

You hand Beliq’s UBL output to your chosen ANAF-immatriculée intermediary (or your in-house ANAF-integrated invoicing software) for the entire operational arc. Beliq’s job ends at a correct, RO_CIUS-valid document.

Mandate is live today, not a phase-in

Unlike Spain VeriFactu (2027 phase-in) or the France Plateforme Agréée reform (2026-2027 phase-in), Romania does not offer a future deadline to plan around. If you issue Romanian B2B or B2G invoices today, you are already in mandate scope:

  • B2G invoices: mandatory since 2022 under OMF 1366/2021.
  • B2B invoices: mandatory since 2024-07-01 under OUG 115/2023, after a soft-launch period in 2024-01 to 2024-06.

The customer’s intermediary stack must be live the day your Beliq integration goes live, not a quarter later. There is no grace window.

Integration architecture (Beliq vs ANAF e-Factura)

Concern In Beliq today Outside Beliq (your stack / partner)
RO_CIUS UBL invoice (Peppol BIS + CIUS-RO overlay) Generate, Validate, Parse —
ANAF SPV submission + certificate authentication Not offered Your ANAF-immatriculée intermediary
XAdES signing of the SPV envelope Not offered Your intermediary
Signed-receipt persistence + audit + retention Not offered Your intermediary or qualified-conservation provider

Generating a Romanian invoice

Address both parties with the Romania VAT scheme (Peppol EAS 9947) via the peppol block. Use ISO 3166-2:RO subdivisions for countrySubentity (for Bucharest, also use one of the SECTOR1..SECTOR6 city codes). Provide either a buyerReference or an orderReference (Peppol requires one). RON is the standard invoice currency; for cross-border invoices in EUR, additionally set taxCurrencyCode and taxTotalInAccountingCurrency to satisfy BR-RO-030 / BR-53.

generate-romania-ro-cius.sh
curl -X POST https://api.beliq.eu/v1/generate \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "standard": "peppol-bis",
    "profile": "romania-ro-cius",
    "output": "xml",
    "invoice": {
      "number": "2026-RO-0001",
      "issueDate": "2026-06-02",
      "currencyCode": "RON",
      "buyerReference": "BUYER-REF-RO-001",
      "seller": {
        "name": "Furnizor SRL",
        "vatId": "RO12345678",
        "peppol": { "schemeId": "9947", "id": "RO12345678" },
        "address": {
          "street": "Strada Exemplu 1",
          "city": "Cluj-Napoca",
          "postalCode": "400000",
          "countryCode": "RO",
          "countrySubentity": "RO-CJ"
        }
      },
      "buyer": {
        "name": "Client SRL",
        "vatId": "RO87654321",
        "peppol": { "schemeId": "9947", "id": "RO87654321" },
        "address": {
          "street": "Bulevardul Test 2",
          "city": "SECTOR1",
          "postalCode": "010101",
          "countryCode": "RO",
          "countrySubentity": "RO-B"
        }
      },
      "lines": [
        {
          "description": "Servicii profesionale",
          "quantity": 10,
          "unitCode": "HUR",
          "unitPrice": 100,
          "lineTotal": 1000,
          "vatRate": 19,
          "vatCategoryCode": "S"
        }
      ],
      "taxSummary": [
        { "vatCategoryCode": "S", "vatRate": 19, "taxableAmount": 1000, "taxAmount": 190 }
      ],
      "totalNetAmount": 1000,
      "totalTaxAmount": 190,
      "totalGrossAmount": 1190
    }
  }'

For the cross-border EUR + RON-tax variant (BR-RO-030), see the Romania RO_CIUS format reference: it documents the exact taxCurrencyCode + taxTotalInAccountingCurrency setup that triggers the second cac:TaxTotal block.

Validation behaviour

The Romania pipeline differs from cross-border Peppol in three places:

  • Two XSLTs fire sequentially. The first (EN16931-CIUS_RO-UBL-validation_v1.0.9.xslt) bakes EN 16931 + Peppol BIS rules in via the Helger compiler and adds the RO_CIUS overlay. The second (ROeFactura-UBL-validation-Invoice_v1.0.9.xslt) layers RO e-Factura operational + VAT rules on top. Errors from both arms merge into one validationResult.errors list with their original Romanian rule IDs.
  • Profile detection rides URN matching. The runtime arm matches both CIUS-RO:1.0.1 (current) and RO_CIUS:1.0.0.2021 (legacy). The Romania arm sits before the generic Peppol arm in dispatch order because the CIUS-RO URN is more specific.
  • Response metadata. Successful validation surfaces profileDetected: "romania-ro-cius", ciusVersion: "1.0.9", and romaniaRoCiusVersion: "1.0.9" alongside the standard EN 16931 fields. See the validation artifacts page for the full response-field map.

Further reading