EDI INVOIC cu Peppol: traducere EDIFACT–Peppol BIS Billing 3 și capcane frecvente
Pentru multe companii enterprise, factura electronică în fluxurile B2B încă înseamnă EDIFACT EDI INVOIC, stabil și bine înrădăcinat în ERP și VAN-uri. În paralel, interoperabilitatea pan-europeană se mișcă accelerat pe Peppol BIS Billing 3 (aliniat la EN 16931 și UBL 2.1), iar echipele IT trebuie să traducă EDI INVOIC în Peppol fără a rupe procesele de contabilitate, TVA și reconciliere. În 2024–2025, presiunea vine atât din obligațiile publice (B2G și, gradual, B2B în mai multe state), cât și din cerința partenerilor comerciali de a primi prin rețeaua Peppol.
Context de piață și conformitate
- Standardul european EN 16931 este baza semantică pentru Peppol BIS Billing 3; majoritatea administrațiilor centrale din UE acceptă e-facturi conform Directivei 2014/55/EU (în vigoare pentru B2G). Germania folosește XRechnung (transportat frecvent prin Peppol), Danemarca NemHandel și Norvegia EHF (B2G obligatoriu încă din 2012) rulează nativ pe Peppol.
- OpenPeppol AISBL coordonează rețeaua Peppol (SML/SMP, profil AS4) activă în peste 40 de țări, inclusiv Australia, Noua Zeelandă și Singapore.
- În România, RO e-Factura a devenit obligatorie în B2B în etape pe parcursul lui 2024 (raportare de la 1 ianuarie și obligativitate generală de emitere/primire de la 1 iulie 2024), bazată pe CIUS-RO derivat din EN 16931. Chiar dacă transportul este național prin Spațiul Privat Virtual/ANAF, tot mai multe grupuri cer și Peppol pentru fluxurile cross-border.
Maparea EDIFACT EDI INVOIC către Peppol BIS Billing 3 (UBL 2.1)
Cheia este să separați nivelul semantic (EN 16931) de sintaxe. Mai jos sunt corespondențele uzuale când transformați EDI INVOIC în UBL:
- Antet document: BGM (tip și număr) → UBL Invoice/ID și InvoiceTypeCode (380=Invoice, 381=Credit Note; atenție, notele de credit se emit ca UBL CreditNote, nu ca facturi negative).
- Date: DTM (data emiterii, data scadenței) → IssueDate, DueDate; data livrării din despatch poate merge în Delivery/ActualDeliveryDate.
- Părți: NAD+BY/SU/IV → AccountingCustomerParty/AccountingSupplierParty; includeți PartyLegalEntity, PartyTaxScheme pentru codurile de TVA. EndpointID este obligatoriu în Peppol (scheme corecte precum 0088 pentru GLN sau 0060 pentru DUNS).
- Monedă: CUX → DocumentCurrencyCode; cursurile pot fi descrise în PricingReference/AllowanceCharge dacă aveți prețuri în monede diferite, dar BIS Billing 3 cere o singură monedă la nivel de document.
- Referințe: RFF (comandă, aviz) → OrderReference/ID, DespatchDocumentReference.
- Linii: LIN/PIA/IMD/QTY/PRI → InvoiceLine/Item/Name, SellersItemIdentification, BuyersItemIdentification, InvoicedQuantity, Price/PriceAmount.
- Taxe: TAX/MOA → TaxTotal/TaxSubtotal cu TaxCategory (coduri EN 16931: S, Z, E, AE etc.) și TaxAmount; aveți grijă la cotele multiple.
- Discount/cheltuieli: ALC/PCD/MOA → AllowanceCharge la nivel de document sau linie (ChargeIndicator true/false, ReasonCode conform listei Peppol).
- Plăți: PAT/PAI → PaymentMeans, PaymentTerms; IBAN/BIC în PayeeFinancialAccount.
- Note/texte: FTX → Invoice/Note sau AdditionalDocumentReference cu atașamente (base64) dacă treceți de limitele de text.
Capcane frecvente când traduceți EDI INVOIC
- Tipuri document: mulți trimit EDI INVOIC 380 pentru toate cazurile. În Peppol, creditarea se face cu document UBL CreditNote; anulările și corecțiile au reguli de referință stricte.
- Rounding: EDIFACT tolerează agregări cu diferențe de rotunjire; Peppol validează matematic TaxTotal, TaxSubtotal și LegalMonetaryTotal. Folosiți 2–4 zecimale la linii și asigurați reconcilieri; altfel obțineți erori schematron.
- TVA categorii: mapări greșite dintre coduri naționale (ex. scutiri locale) și categoriile EN 16931 duc la respingeri. Verificați că S, Z, E, AE corespund regulilor de business din jurisdicție.
- AllowanceCharge: ALC “miscellaneous” din EDI INVOIC devine adesea AllowanceCharge fără ReasonCode valid. Peppol cere coduri controlate (de ex. 95 freight, 41 discount) și poziționare corectă (linie vs total).
- EndpointID: trimiterea către un ID incorect sau cu scheme greșite blochează livrarea în rețea. Verificați prin SMP că participantul are serviciul BIS Billing 3 activ.
- UOM și clasificări: unități ne-UN/ECE sau lipsa ItemClassificationCode (UNSPSC) pot trece tehnic dar blochează auto-matching-ul ERP la client.
- Acknowledgements: în EDI INVOIC vă bazați pe CONTRL; în Peppol primiți transport receipts AS4 și, opțional, business-level responses (MLR). Nu confundați cu acceptarea contabilă.
- Note de credit parțiale: nu trimiteți linii negative într-un Invoice; folosiți CreditNote cu legare la factura inițială via BillingReference.
Arhitectură: Access Point, SMP/SML, securitate
Peppol folosește descoperirea prin SML/SMP și transport AS4. Alegeți un Access Point certificat (Basware, Pagero, Comarch, Unifiedpost, TIE Kinetix, SAP Business Network ș.a.) care suportă nativ maparea EDI INVOIC ↔ BIS Billing 3 și validările EN 16931/Peppol. Integrarea prin API vă permite să mențineți EDI INVOIC în ERP, iar conversia în Peppol BIS Billing 3 să se facă la marginea rețelei. Microsoft Dynamics 365, SAP S/4HANA (prin SAP Document and Reporting Compliance) și Oracle au conectori disponibili via parteneri AP.
Strategie pentru IT: pași practici
- Stabiliți canonical intern: păstrați EDI INVOIC ca format sursă, dar normalizați semantic la EN 16931 înainte de export.
- Implementați validare dublă: schematron Peppol + reguli fiscale locale (de ex. RO e-Factura pentru România, XRechnung pentru Germania).
- Gestionați identități: întrețineți un registry de EndpointID/ID schemă per partener. Automatizați interogarea SMP.
- Monitorizați end-to-end: corelați Message-ID AS4 cu Invoice/ID și status-urile business (received/accepted/rejected).
- Consolidați excepțiile: diferențe de rotunjire, schimbări de TVA, lipsă PO — trimiteți către un queue de remediere, nu respingeți automat.
În România, integratori locali precum EDIconnect.ro (modul CRMconnect) sau jucători globali ca Pagero/Basware pot acoperi atât RO e-Factura, cât și livrarea cross-border prin Peppol, inclusiv conversia din EDI INVOIC.
Concluzie
Migrarea de la EDIFACT EDI INVOIC la Peppol BIS Billing 3 nu este doar o schimbare de sintaxă; este o aliniere la un model semantic strict, validat, cu beneficii de interoperabilitate și automatizare. Echipele IT, consultanții ERP și specialiștii EDI care tratează riguros mapările, codurile de TVA, AllowanceCharge și managementul EndpointID vor livra facturi care trec de primul foc automat al validatoarelor Peppol. Într-o piață unde B2G este deja standardizat și B2B devine rapid obligatoriu în mai multe țări, un flux robust EDI INVOIC ↔ Peppol BIS Billing 3 este diferența dintre “trimis” și “încasat”.