Peppol BIS Billing 3.0 a devenit standardul de facto pentru facturarea electronică EDI între companii și instituții publice în UE și în piețe precum Singapore, Australia sau Noua Zeelandă. Odată cu generalizarea profilului AS4 în rețea, mulți implementatori confundă confirmările de transport (AS4 Receipt/Error) cu confirmarea de business EDI – Business ACK (numită în Peppol Message Level Response, MLR). Pentru un flux robust de e‑facturare EDI, Business ACK în Peppol BIS Billing 3.0 trebuie proiectat și configurat explicit end‑to‑end.
Business ACK în Peppol: ce este și de ce contează
Business ACK în Peppol este o notificare de nivel aplicație, transmisă ca UBL ApplicationResponse conform specificației Peppol Message Level Response 3.0. Scopul ei este să indice starea de prelucrare de business a unei facturi EDI (de ex. acceptată, respinsă, acceptată condiționat), independent de transport. Spre deosebire de AS4 Receipt (care atestă doar livrarea tehnică), Business ACK reflectă rezultatul validărilor EN 16931 și regulilor de business interne ale cumpărătorului.
În MLR se face referință la factura EDI inițială (ID, IssueDate, UUID) și se utilizează coduri conforme UNCL 4343 (de ex., Accepted, Rejected, Conditionally accepted). Dacă respingerea derivă din abateri față de EN 16931/Peppol BIS Billing 3.0, este recomandat să se includă identificatori de regulă (de tip BR-CO-xx) și explicații, pentru ca emițătorul EDI să poată corecta rapid.
AS4 vs. Business ACK: separați straturile
Profilul AS4 din Peppol impune one‑way push, semnătură și criptare end‑to‑end, non‑repudiere prin Receipts semnate și retry controlat. Acesta rezolvă livrarea EDI sigură și trasabilă, dar nu acoperă acceptarea de business. O arhitectură sănătoasă tratează clar:
- Transport ACK (AS4 Receipt/Error): confirmă primirea tehnică a documentului EDI în Access Point.
- Business ACK (MLR): confirmă starea de procesare a documentului EDI în aplicația destinatarului.
Cele 7 lucruri care trebuie configurate pentru Business ACK în Peppol BIS Billing 3.0
-
Identități Peppol corecte (ISO 6523) și SMP
- Asigurați-vă că ID‑urile participanților EDI sunt corecte (de ex., 0088 pentru GLN, 9906 pentru DUNS) și publicate în SMP.
- Publicați în SMP capabilitatea de a PRIMI MLR pe partea furnizorului (emițătorul facturii EDI). Fără această capabilitate, cumpărătorul nu poate ruta Business ACK‑ul înapoi.
-
Maparea proceselor și a ProcessIdentifier
- Factura EDI BIS Billing 3.0 și MLR trebuie să aibă ProcessIdentifier corelat (profilul MLR pentru billing). Verificați ca SBDH să includă corect DocumentTypeIdentifier și ProcessIdentifier atât la factură, cât și la MLR.
-
P‑Mode AS4 în Access Point
- Configurați P‑Mode pentru one‑way push cu semnare și criptare (XML‑DSig, X.509 din PKI Peppol), Receipts semnate și retries cu back‑off.
- Activați compresia, limite rezonabile la payload și jurnalizare pentru probe de livrare (non‑repudiere).
-
Certificare PKI Peppol și rotație
- Folosiți certificate emise de autoritatea PKI OpenPeppol pentru mediile Test/Prod și urmăriți expirarea. Automatizați rotația și re‑publicarea în SMP.
-
Validare și corelare în ERP/EDI back‑end
- Mențineți corelarea invoiceID/UUID ↔ MLR și un state machine: Sent → Delivered (AS4) → Accepted/Rejected (MLR).
- Generați MLR automat la primirea facturii EDI: Accepted dacă trece validările EN 16931 + regulile interne; Rejected cu detalii clare altfel.
-
Reguli de business și transparentețe
- Includeți în MLR motive lizibile și coduri standardizate. Exemplu: “BR‑CO‑10: Total tax inconsistent” sau “Missing Buyer reference”.
-
Monitorizare și SLA
- Definește KPI separați: Timp mediu până la AS4 Receipt (secunde) vs. timp mediu până la MLR (minute/ore). Alertați când MLR lipsește peste o fereastră agreată (ex. 24h).
Stack tehnic și opțiuni de implementare
Pentru Access Point și AS4, ecosistemul oferă opțiuni mature:
- Open source: Oxalis (utilizat istoric pe Peppol, integrabil cu Holodeck B2B pentru AS4) și Holodeck B2B ca motor AS4.
- Furnizori AP consacrați: Pagero, Basware, Comarch, OpenText, Unifiedpost, TIE Kinetix, Sovos – toți oferă conectivitate EDI la Peppol, validări EN 16931 și suport pentru MLR.
În ERP, multe produse enterprise (SAP S/4HANA, Microsoft Dynamics 365, Oracle ERP) pot emite/consuma UBL, însă pentru MLR este necesară integrarea EDI specifică Peppol. Recomandare: izolați adaptorul Peppol (generare SBDH, semnare, MLR) într-un micro‑serviciu, versiuneați regulile și schematroanele, și expuneți stările către ERP prin webhook/queue.
Context de piață și conformitate
Pe fondul extinderii e‑facturării EDI în UE, BIS Billing 3.0 aliniat EN 16931 rămâne obligatoriu în achizițiile publice și tot mai frecvent în B2B. Franța a amânat mandatul B2B până cel mai devreme în 2026, în timp ce Germania introduce recepția obligatorie a facturilor electronice de la 1 ianuarie 2025, cu tranziție etapizată ulterior. România a extins utilizarea e‑Factura în 2024 pentru B2B la nivel național (sistemul RO e‑Factura), iar Peppol rămâne calea recomandată pentru tranzacții transfrontaliere EDI.
Capcane frecvente
- Publicare SMP incompletă: furnizorul nu publică suport pentru MLR, iar cumpărătorul nu poate trimite Business ACK.
- Confuzie între Receipt AS4 și MLR: se marchează greșit factura ca “acceptată” după Receipt; în realitate este doar livrată tehnic.
- Neconcordanță DocumentType/ProcessIdentifier în SBDH între factură EDI și MLR → rutare eșuată.
- Omiterea detaliilor de respingere în MLR → cicluri lente de corecție și costuri EDI crescute.
Concluzie
Pentru un flux EDI profesionist în Peppol BIS Billing 3.0, Business ACK nu este “opțional”, ci elementul care închide bucla de control. Cheia este configurarea corectă a capabilităților în SMP, P‑Mode AS4 robust, validări EN 16931 automatizate și o mapare clară a stărilor în ERP. Alegeți un Access Point și un stack EDI care oferă MLR end‑to‑end și instrumente de monitorizare, iar echipa IT va avea vizibilitate și control real asupra conformității și performanței procesului de facturare electronică.