ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

SPV — Spațiul Privat Virtual

SPV (Spațiul Privat Virtual) is the unified ANAF portal for every electronic tax procedure in Romania. Launched in 2014 for individuals and businesses, it became in 2022 the only entry point for e-Factura, e-Transport, D406 SAF-T, e-Sigilii and the D300 VAT declaration.

SPV's role in the ANAF ecosystem

SPV is more than an e-Factura portal: it is the unique interface between a Romanian taxpayer and ANAF for the full spectrum of digital tax procedures.

  • e-Factura: issuance, validation, retrieval of B2B and B2G invoices. The main and most voluminous flow since January 2025.
  • e-Transport: declaration of high-value goods (> €500K) crossing Romanian borders. UIT companion document.
  • D406 — Romanian SAF-T: mandatory monthly informative declaration of supplies / services / acquisitions.
  • e-Sigilii: digital fiscal seals for excisable goods (tobacco, alcohol).
  • VAT declarations: D300, D390, D394 — historically filed on SPV before e-Factura arrived.
  • ANAF mail reception: verification notices, summonses, fiscal certificates, VAT taxpayer attestations — all land in the SPV inbox.

Authentication — eIDAS qualified certificate

SPV access requires a qualified certificate within the meaning of the eIDAS regulation, issued by a Romanian provider certified by ADR (Autoritatea pentru Digitalizarea României):

  • CertSign — historic leader, ~40% market share, native ANAF integration since 2008.
  • DigiSign — second player, strongly present in retail and pharma.
  • Trans Sped — particularly popular among multinationals and foreign companies with Romanian tax representation.
  • CertDigital — new entrant, cloud-native integration for modern ERPs.

The taxpayer must first create an SPV account via the web portal by presenting their physical certificate (USB token or smart card). Once the account is bound to the CUI, they can generate OAuth client_id / client_secret pairs for their ERPs and API clients.

REST API for e-Factura

The e-Factura API rests on OAuth 2.0 with the client_credentials flow. Step 1 — obtain an access_token:

http anaf-oauth-token.http
POST https://logincert.anaf.ro/anaf-oauth2/v1/token
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <base64(client_id:client_secret)>

grant_type=client_credentials&scope=e-factura

HTTP/1.1 200 OK
{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600
}

Step 2 — send the RO_CIUS UBL invoice. The XML must be valid against the OASIS UBL 2.1 XSD and satisfy the RO_CIUS Schematron rules published by ANAF:

http anaf-upload-call.http
POST https://api.anaf.ro/test/FCTEL/rest/upload?standard=UBL&cif=12345678
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
Content-Type: application/xml
Content-Encoding: gzip

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
  <cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:efactura.mfinante.ro:CIUS-RO:1.0.1</cbc:CustomizationID>
  ...
</Invoice>

HTTP/1.1 200 OK
<header xmlns="mfp:anaf:dgti:efactura:respUploadFisier:v1"
  index_incarcare="12345678" data_raspuns="202605191430" Cif_emitent="12345678"
  ExecutionStatus="0">
</header>

The index_incarcare is the ANAF internal transaction number. The validation result is fetched in a second call, typically 10-60 seconds later, on the /stareMesaj?id_incarcare=<index> endpoint.

Key endpoints

EndpointMethodPurpose
/upload?standard=UBL&cif=...POSTUBL invoice submission
/uploadb2c?...POSTB2C invoice submission (since OUG 69/2024)
/stareMesaj?id_incarcare=...GETValidation status (XML response)
/descarcare?id=...GETZIP archive download (signed XML + PDF render)
/listaMesajeFactura?zile=...&cif=...GETList of incoming / outgoing messages (60 days max)
/listaMesajePaginatieFactura?...GETPaginated list with advanced temporal filters
/api/oauth2/v1/tokenPOSTOAuth 2.0 access_token issuance

SFTP — batch submission

For large volumes (typically > 10,000 invoices/day), ANAF provides a dedicated SFTP channel. The taxpayer drops a ZIP file containing N UBL invoices and an XML manifest describing the batch:

  • Endpoint: sftp.anaf.ro port 22, authentication with public key + password + IP whitelist.
  • Naming convention: CIF_YYYYMMDDHHMMSS_NN.zip where NN is the incremental batch number.
  • Max size: 50 MB per ZIP, 5,000 invoices per batch.
  • Result: a return ZIP is dropped in /out/<CIF>/ containing statuses and signed XML. SFTP polling is recommended every 60 seconds.

Retry policy and unavailability

The e-Factura API is dimensioned for ~50 million invoices per month at cruising speed. ANAF's recommended retry policy:

  • 4xx errors: do not retry — the error is functional (invalid XML, wrong CIF, security). Fix and resubmit.
  • 5xx errors or timeouts: exponential backoff — 1s, 2s, 4s, 8s, 16s, 32s, max 5 attempts.
  • Unavailability > 24h: ANAF publishes a declarație de indisponibilitate on the portal. During this window, the taxpayer may issue in degraded mode (PDF with mention) and must resubmit within 5 working days post-restoration.
  • Planned maintenance: Sunday 02:00-06:00 Bucharest time (UTC+2). Announcements 7 days in advance on the ANAF portal.

Volume and performance

  • Cumulative volume: > 500 million e-Factura invoices processed between January 2023 (B2G pilot) and end of 2025 (universal B2B).
  • Daily peak: ~12 million invoices/day measured in March 2025 (close to D406 deadline).
  • Target latency: < 10s for 95% of invoices, < 60s for 99.9%.
  • Validation error peak: 4-8% of submissions rejected (typically CIF errors, VAT codelist, EN 16931 BR-CO-XX mismatches).
  • 2025 availability: 99.6% measured (incidents mostly in September 2025 during Microsoft Azure cloud migration).

Common pitfalls

  • Time gap between upload and ANAF signature. Do not consider the invoice as issued until ExecutionStatus=0 is confirmed by /stareMesaj. Status 1 = error, 2 = in progress, 3 = signed.
  • 60-day retention window. SPV only keeps invoices for 60 days in fast access. For long-term archival, the taxpayer must download via /descarcare and store locally.
  • Certificate / CIF mismatch. An eIDAS certificate must be bound to a CIF in SPV. Attempting to issue with a certificate not bound to the issuer CIF returns a 401 error.
  • OAuth token expiration. Access tokens are valid for 1 hour. For long batches, plan a systematic refresh every 50 minutes.
  • UTF-8 encoding vs BOM. XML files must be in strict UTF-8, without BOM. The BOM causes an ANAF parsing error.