SPV — Spațiul Privat Virtual

Le SPV (Spațiul Privat Virtual) est le portail unifié de l'ANAF pour toutes les démarches fiscales électroniques en Roumanie. Lancé en 2014 pour les particuliers et entreprises, il est devenu en 2022 le seul point d'entrée pour e-Factura, e-Transport, D406 SAF-T, e-Sigilii et la déclaration de TVA D300.

Rôle du SPV dans l'écosystème ANAF

Le SPV est plus qu'un portail e-Factura : c'est l'unique interface entre un contribuable roumain et l'ANAF pour l'ensemble des démarches fiscales numériques.

• e-Factura : émission, validation, récupération des factures B2B et B2G. Le flux principal et le plus volumineux depuis janvier 2025.
• e-Transport : déclaration des marchandises franchissant les frontières roumaines à haute valeur (> 500 000 €). Document UIT compagnon.
• D406 — SAF-T roumain : dépôt mensuel obligatoire de la déclaration informative des livraisons / prestations / achats.
• e-Sigilii : sceaux fiscaux numériques pour marchandises soumises à accise (tabac, alcool).
• Déclarations TVA : D300, D390, D394 — déposées historiquement sur SPV avant l'arrivée d'e-Factura.
• Réception courrier ANAF : avis de vérification, somations, certificate fiscal, attestation de plătitor de TVA — tous arrivent dans la boîte SPV.

Authentification — certificat qualifié eIDAS

L'accès SPV exige un certificat qualifié au sens du règlement eIDAS, émis par un prestataire roumain certifié auprès de l'ADR (Autoritatea pentru Digitalizarea României) :

• CertSign — leader historique, ~40 % de parts de marché, intégration ANAF native depuis 2008.
• DigiSign — second acteur, fort présent dans le retail et la pharma.
• Trans Sped — particulièrement populaire pour les multinationales et les sociétés étrangères avec représentation fiscale en Roumanie.
• CertDigital — nouvel entrant, intégration cloud-native pour ERP modernes.

Le contribuable doit d'abord se créer un compte SPV via le portail web en présentant son certificat physique (USB token ou carte à puce). Une fois le compte associé au CUI, il peut générer des couples client_id / client_secret OAuth pour ses ERP et clients API.

API REST e-Factura

L'API e-Factura repose sur OAuth 2.0 avec le flux client_credentials. Étape 1 — obtenir un access_token :

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
}

Étape 2 — envoyer la facture UBL RO_CIUS. Le XML doit être valide selon l'XSD UBL 2.1 publié par OASIS et respecter les règles Schematron RO_CIUS publiées par l'ANAF :

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>

L'index_incarcare est le numéro de transaction interne ANAF. Le résultat de la validation est récupéré dans un second appel, typiquement 10-60 secondes plus tard, sur l'endpoint /stareMesaj?id_incarcare=<index>.

Endpoints clés

SFTP — soumission batch

Pour les grands volumes (typiquement > 10 000 factures / jour), l'ANAF propose un canal SFTP dédié. Le contribuable dépose un fichier ZIP contenant N factures UBL et un manifest XML décrivant le batch :

• Endpoint : sftp.anaf.ro port 22, authentification clé publique + mot de passe + IP whitelist.
• Convention de nommage : CIF_AAAALLJJHHMMSS_NN.zip où NN est le numéro de batch incrémental.
• Taille max : 50 Mo par ZIP, 5 000 factures par batch.
• Résultat : un ZIP de retour est déposé dans /out/<CIF>/ contenant les statuts et les XML signés. Le polling SFTP est recommandé toutes les 60 secondes.

Politique de retry et indisponibilité

L'API e-Factura est dimensionnée pour ~50 millions de factures par mois en régime de croisière. La politique de retry recommandée par l'ANAF :

• Erreurs 4xx : ne pas retry — l'erreur est métier (XML invalide, CIF incorrect, sécurité). Corriger et resoumettre.
• Erreurs 5xx ou timeout : backoff exponentiel — 1s, 2s, 4s, 8s, 16s, 32s, max 5 tentatives.
• Indisponibilité > 24h : l'ANAF publie une declarație de indisponibilitate sur le portail. Pendant cette période, le contribuable peut émettre en mode dégradé (PDF avec mention) et doit resoumettre dans les 5 jours ouvrés post-rétablissement.
• Maintenance planifiée : dimanche 02h-06h heure de Bucarest (UTC+2). Annonces 7 jours avant sur le portail ANAF.

Volumétrie et performance

• Volume cumulé : > 500 millions de factures e-Factura traitées entre janvier 2023 (B2G pilote) et fin 2025 (B2B universel).
• Pic journalier : ~12 millions de factures / jour mesuré en mars 2025 (proche échéance D406).
• Latence cible : < 10s pour 95 % des factures, < 60s pour 99,9 %.
• Pic d'erreurs validation : 4-8 % des soumissions rejetées (généralement codes erreur CIF, codelist TVA, mismatch EN 16931 BR-CO-XX).
• Disponibilité 2025 : 99,6 % mesurée (incidents principalement en septembre 2025 lors de migration infrastructure cloud Microsoft Azure).

Pièges courants

• Délai entre upload et signature ANAF. Ne pas considérer la facture comme émise tant que l'ExecutionStatus=0 n'est pas confirmé par /stareMesaj. Un statut 1 = erreur, 2 = en cours, 3 = signé.
• Période de rétention 60 jours. Le SPV ne conserve les factures que 60 jours en accès rapide. Pour archivage long terme, le contribuable doit télécharger via /descarcare et stocker localement.
• Mismatch certificat / CIF. Un certificat eIDAS doit être lié à un CIF dans SPV. Tenter d'émettre avec un certificat non lié au CIF émetteur renvoie une erreur 401.
• Token OAuth expiration. Les access_token sont valides 1 heure. En cas de batch long, prévoir un refresh systématique toutes les 50 minutes.
• Encodage UTF-8 vs BOM. Les XML doivent être en UTF-8 strict, sans BOM. Le BOM provoque une erreur de parsing ANAF.

Liens transverses

• Hub Roumanie — e-Factura ANAF complet
• e-Factura — clearance pur RO_CIUS
• RO_CIUS — customization UBL 2.1
• Calendrier déploiement 2022-2025
• D406 — SAF-T roumain
• e-Transport — document compagnon
• ANAF — SPV portail officiel
• ANAF — spécifications techniques API
• ADR — Autoritatea pentru Digitalizarea României