APERAK: Alinierea mesajelor de respingere cu procesele interne de validare a facturilor (context RO e-Factura)

De la 1 iulie 2024, România a trecut în regim obligatoriu la e-Factura pentru tranzacțiile B2B, aliniată la standardul european EN 16931 (CIUS RO pe sintaxa UBL 2.1) și livrată prin Spațiul Privat Virtual (SPV) al ANAF. În acest context, pentru companii cu peisaje IT complexe (SAP, Microsoft Dynamics 365, Oracle NetSuite, SeniorERP, SAGA, etc.), cheia operațională nu este doar trimiterea facturii, ci închiderea buclei de feedback: a transforma respingerile și erorile sistemului public în evenimente acționabile. Aici intervine APERAK, mesajul EDIFACT de Application Error and Acknowledgement, folosit pe scară largă în EDI pentru a confirma și detalia erorile la nivel de aplicație.

Ce este APERAK și de ce contează în e-Factura

APERAK este un mesaj EDIFACT standard, complementar lui CONTRL (acknowledgement de transport), care transmite acceptări/respingeri la nivel de business și detalii despre erori. În România, ANAF returnează stări și mesaje de eroare în urma validărilor sintactice și semantice pe fișierele XML UBL. În practică, multe organizații mapează răspunsurile ANAF în APERAK, pentru că ecosistemul EDI și ERP știe să consume un APERAK și să-l coreleze cu documente interne. Astfel, APERAK devine limbajul comun între gateway-ul e-Factura, EDI hub și ERP, standardizând respingerile.

Alinierea APERAK la procesele interne de validare

O arhitectură robustă tratează APERAK ca eveniment de business, nu ca simplă notificare tehnică. Recomandări:

• Corelare prin chei stabile: număr factură + data + CUI, respectiv identificatorul intern al documentului. În plus, păstrați corelația cu ID-urile ANAF (de ex. id-ul de încărcare din SPV) pentru trasabilitate end-to-end în APERAK.
• Taxonomie comună de erori: normalizați codurile interne și mesajele ANAF în categorii procesuale (date master lipsă, inconsecvențe de TVA, diferențe de preț, sintaxă XML, duplicat). APERAK transmite categoria și severitatea.
• Orchestrare printr-un event bus (Kafka/RabbitMQ/Azure Service Bus): fiecare APERAK declanșează un flux (task de corecție în ERP, notificare către furnizor, automatizare de reemitere). SLA-urile de rezolvare devin metrice operaționale.
• Separarea ACK-urilor: folosiți în continuare CONTRL/MDN/HTTP 200 pentru transport, iar APERAK pentru semnificația business. Evitați să suprapuneți niveluri diferite în același mecanism.

Tipuri uzuale de respingeri mapate în APERAK

• Sintaxă UBL/semnătură: structură XML incorectă, semnătură invalidă, elemente obligatorii lipsă. APERAK include locația XPath și regula încălcată.
• Reguli semantice EN 16931/CIUS RO: inconsecvențe între totaluri, linii, TVA, unități de măsură; coduri de taxare incorecte. APERAK mapează regula și exemplifică valorile așteptate.
• Business/localizare: CUI invalid/inactiv, NIF greșit, adresă incompletă, duplicate detectate în fereastra de timp. APERAK indică statusul registrului ANAF în momentul validării.

În retail, de exemplu, Kaufland România, Carrefour sau Auchan utilizează de ani buni EDI pentru ORDERS/DESADV/INVOIC; integrarea e-Factura adaugă un strat public de validare. APERAK unifică respingerile publice cu cele private (ex. diferențe de preț față de contract, lipsă recepție/NIR) într-un singur canal către ERP.

Starea pieței și tehnologii enterprise

România este a doua mare economie din UE care impune e-Factura B2B la nivel național, după Italia. B2G este obligatoriu din 2022, iar B2B din 1 iulie 2024, cu perioadă de raportare extinsă în H1 2024. Soluțiile enterprise au răspuns rapid:

• SAP S/4HANA prin Document and Reporting Compliance (DRC) oferă conector pentru RO e-Factura și poate emite/consuma APERAK în peisaje EDI existente.
• Microsoft Dynamics 365 are modulul Electronic Invoicing și Globalization Studio pentru România, integrabil cu APERAK prin adaptări.
• Oracle NetSuite și alte ERP locale (SeniorERP, SAGA, Charisma) folosesc fie conectori direcți la SPV, fie gateway-uri EDI care livrează APERAK către ERP.

Pe plan european, Franța a amânat calendarul e-facturării B2B pentru 2026–2027, iar Polonia a reprogramat KSeF pentru 2026. Pentru organizațiile regionale, standardizarea pe APERAK reduce costul de integrare cross-country, deoarece pattern-ul de feedback rămâne stabil, indiferent de platforma fiscală națională.

Pattern-uri de implementare APERAK

• Canonical error model: definiți un model intern (JSON/EDIFACT) pentru APERAK și mapări dedicate pe fiecare sursă (ANAF, EDI privat, verificări ERP). Acest model devine contractul între echipe.
• Retry/reattempt: pentru erori tranzitorii (timing, indisponibilitate serviciu), APERAK marchează eroarea ca retryable și trigger-ează reîncărcarea controlată.
• Observabilitate: corelați APERAK cu facturile în APM/observability (Grafana, Splunk, Elastic) și expuneți KPI-uri: rata de first-pass acceptance (FPA), time-to-fix, număr APERAK/1000 facturi.

Companiile care au implementat APERAK ca eveniment cheie raportează creșterea FPA cu 10–20% în primele luni și reducerea lead-time-ului de încasare pentru B2B. Pentru IMM-uri sau integrări rapide, furnizori EDI locali pot oferi adaptorul APERAK gata de folosit; de exemplu, EDIconnect.ro, ca modul al CRMconnect, expune APERAK standardizat către ERP-uri diverse.

Capcane frecvente

• Confundarea statelor de transport cu stările de business: un HTTP 200 nu înseamnă acceptare fiscală; APERAK trebuie să reflecte verdictul validărilor ANAF.
• Erori „mute”: respingeri fără ticket operațional. Integrați APERAK cu servicii de alertare (Opsgenie, PagerDuty) și cu backlog-ul echipei de contabilitate/aprovizionare.
• Lipsa actualizării CIUS RO: regulile se ajustează periodic; mențineți mapările APERAK și validatorul la versiuni curente pentru a evita respingeri masive.

Concluzie

În peisajul RO e-Factura, APERAK nu este doar „încă un fișier EDI”, ci mecanismul prin care respingerile devin controlabile, măsurabile și reparabile în timp util. Standardizarea pe APERAK, corelată cu un model canonic de erori și o orchestrare bazată pe evenimente, conectează ANAF, EDI și ERP într-un lanț coerent. Rezultatul: mai puține reemisii, un FPA mai mare, cash-flow mai predictibil și conformitate sustenabilă, indiferent de volumul sau complexitatea pe care o aveți.