Romania

Romanian B2B/B2G e-invoicing with Beliq, RO_CIUS UBL (Romania's CIUS of EN 16931), 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 RO_CIUS / CIUS-RO 1.0.9, Romania’s national CIUS of EN 16931, which Beliq builds and checks in UBL. It is governed by ANAF (Agenția Națională de Administrare Fiscală) via the Ministry of Finance. Authority publication lives at mfinante.gov.ro. Beliq checks a Romanian invoice against CEN’s EN 16931 UBL Schematron and phive-rules’ compilation of ANAF’s CIUS-RO Schematron; no Peppol BIS Billing 3.0 rule runs on it (see validation behaviour).

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.

• 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 Romanian UBL against the dual-XSLT Schematron arm vendored from the Helger phive-rules-cius-ro 4.6.4 JAR (Maven Central). The two XSLTs are the phive-rules project’s compilation of the CIUS-RO Schematron that ANAF publishes, not ANAF’s own files, so Romanian results are Community-checked (see how verification works). 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. Validation errors carry BR-RO-* rule IDs from either the CIUS-RO or the RO e-Factura XSLT. Parse reads its fields and runs no rules.

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.

Today 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. Managed delivery is in build, and the ANAF SPV channel is not one of its launch lanes.

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: both obligations below are in force today.

• B2G invoices: mandatory since 2022-07-01 for operators established in Romania, under Legea 139/2022 (art. II).
• B2B invoices: sent to the buyer only through RO e-Factura since 2024-07-01, under Legea 296/2023 (art. LXV and LXX) as amended by OUG 115/2023 (art. LXVIII). Who is covered and who is excepted is set by articles 10 to 10^10 of OUG 120/2021 as they stand.

Last verified against the consolidated OUG 120/2021, Legea 139/2022, Legea 296/2023 and OUG 115/2023 on legislatie.just.ro on 3 November 2026. Official source.

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

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: POST /v1/generate refuses an invoice with neither (400), although no rule that runs on a Romanian invoice 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.

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",
      "dueDate": "2026-07-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.

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

• Two XSLTs fire sequentially, after CEN’s EN 16931 UBL Schematron. The first (EN16931-CIUS_RO-UBL-validation_v1.0.9.xslt) is phive-rules’ compilation of most of the EN 16931 rules and the RO_CIUS rules, with no Peppol BIS rule, so CEN’s pack keeps running beside it. The second (ROeFactura-UBL-validation-Invoice_v1.0.9.xslt) layers RO e-Factura operational + VAT rules on top. Errors from all three merge into one validationResult.errors list with their original 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.

• Romania RO_CIUS format reference: exhaustive field map, CIUS-RO rule catalogue summary, cross-border multi-currency example.
• Peppol BIS format reference: the UBL layout the generator also uses for Romanian invoices.
• Validation artifacts: vendored Schematron + version pin.
• ANAF technical hub (mfinante.gov.ro): authority spec PDFs + Schematron source.
• Helger phive-rules-cius-ro: upstream rule pack used at vendor time (its code is Apache-2.0; the rules’ licence is under Licences and attribution).