E‑Rechnungen prüfen: ZUGFeRD, XRechnung, Peppol und EN 16931 verstehen

Divendres, 15:40 h: L’arribada de factures està aturada. No completament – però exactament prou perquè faci mal. Una part de les factures electròniques entrants passa netament, una altra queda encallada a la via d’importació. L’àrea funcional diu: «Al PDF sembla tot correcte.» IT veu al log: «Perfil no permès» i «S’ha violat una regla de negoci». A partir d’aquí es torna polític: Compres vol volum, Comptabilitat vol seguretat, i IT no vol lògica especial per a cada proveïdor.

Qui en aquesta situació ha de comprovar factures electròniques s’adona ràpidament: ZUGFeRD, XRechnung, Peppol i EN 16931 no són una qüestió de matisos terminològics, sinó una valoració. Depenent de com d’exigent sigui la comprovació, es desplacen esforç i risc – i amb això també les decisions d’arquitectura (servei de validació centralitzat vs. connector al ERP), qüestions d’operació (monitoratge, actualitzacions, fallback) i qüestions de desplegament (grups pilot, comunicació amb proveïdors, classes d’errors).

Dos objectius que en el dia a dia es contraposen

Objectiu 1: Automatització amb alt rendiment. Moltes empreses volen dissenyar l’entrada de factures perquè les factures estructurades arribin sense ruptures de medi a l’ERP, al workflow i a l’arxiu. Això redueix la captació manual i accelera les aprovacions – però només si les dades són fiables.

Objectiu 2: seguretat de la comprovació amb prova rastrejable. Alhora, en cas de dubte, cal poder justificar per què una factura es va acceptar o rebutjar: quin perfil, quina regla, quina versió. Això esdevé rellevant com a mínim quan els proveïdors reclamen („heu rebutjat, però a d’altres els ha funcionat“) o quan els controls interns demanen una cadena documental neta.

Tots dos objectius són legítims. El conflicte sorgeix perquè cada comprovació addicional redueix riscos però també pot generar més casos especials. Això és especialment cert quan els proveïdors envien perfils diferents o quan un canvi de versió en l’especificació encara no s’ha propagat arreu.

EN 16931: Per què ha de gestionar la semàntica en lloc del „format de fitxer“ a l’hora de comprovar

EN 16931 sovint s’anomena en el dia a dia del projecte „el format XML“. Més útil pràcticament és una altra perspectiva: EN 16931 és el model de dades semàntic per als elements clau d’una factura electrònica – és a dir, el significat dels camps de dades i les regles de negoci (Business Rules) associades per a la conformitat. La Comissió Europea classifica EN 16931 exactament així: com un model de dades semàntic dels elements clau incloent-hi regles de conformitat.^[Quelle]

La conseqüència pràctica per a IT i explotació: „XML està ben format“ n’és només la porta d’entrada. El que és determinant és si una factura és consistent pel que fa al significat (lògica de sumes, indicacions fiscals, camps obligatoris, codis). I si es presenta en el perfil correcte – perquè els perfils determinen quines parts de l’estàndard i en quina forma s’apliquen.

També és important que els estàndards no es congelin. Als registres de normes ja figura una edició actualitzada com EN 16931‑1:2026.^[Quelle] Això no vol dir que hagueu de canviar immediatament. Vol dir, però, que el vostre model de comprovació i operacions hauria d’estar dissenyat perquè els conjunts de regles i els validadors puguin ser versionats i actualitzats de manera controlada – sense que tot el procés estigui „al límit“ cada vegada que hi hagi una actualització.

ZUGFeRD i XRechnung: Dos camins per fer pràcticament la mateixa obligació

A Alemanya, en moltes empreses es troben dues formes comunes:

• ZUGFeRD com a format híbrid: un fitxer PDF/A‑3 en què s’imbauen dades de factura estructurades (XML). FeRD descriu explícitament ZUGFeRD 2.2 com a model híbrid: document visible més XML llegible per màquina dins d’un PDF/A‑3.^[Quelle]
• XRechnung com a format purament estructurat: l’enfocament se centra completament en dades processables per màquina, sense que un PDF vagi integrat com a component.

La ponderació és menys ideològica i més operativa: ZUGFeRD sovint és més fàcil d’acceptar pels departaments funcionals perquè existeix un justificant llegible. Al mateix temps, el PDF no ha d’induir a descuidar la comprovació de l’XML. XRechnung és clarament orientada a les dades i per això és adequada per a l’automatització, però en la pràctica gairebé sempre requereix una bona eina de visualització i validació que presenti el contingut de manera entenedora.

Marc legal: Què comptarà com a „factura electrònica“ a partir del 2025

Per a la planificació del projecte, una afirmació és especialment efectiva: en el context de l’IVA, a partir de l’01.01.2025 només s’entén que hi ha una factura electrònica si aquesta s’expedeix/transmet/rep en un format electrònic estructurat i permet el processament electrònic.^[Quelle] Un PDF pur sense dades estructurades no s’ajusta, per tant, a la definició rellevant aquí.

El BMF indica també XRechnung i ZUGFeRD a partir de la versió 2.0.1 (amb excepcions de perfil) com a formats que, en principi, compleixen els requisits de l’IVA.^[Quelle] A nivell operatiu, això no és una „qüestió religiosa de format“, sinó una obligació clara: heu de reconèixer, verificar i documentar de manera traçable el perfil i la versió. Si no, no serà possible ni un punt de control fiable ni una justificació clara del motiu pel qual una factura es va tractar d’una determinada manera.

Classificar correctament Peppol: Transport i interoperabilitat en lloc de „encara un format”

Peppol sovint es tracta en el dia a dia com un altre format de factura. Això genera expectatives errònies. Peppol és, en primer lloc, un marc de transmissió i interoperabilitat per a documents comercials estructurats. Per a factures, Peppol BIS Billing 3.0 és el component rellevant.

En la documentació oficial de BIS-Billing, la conformitat EN‑16931 és visible mitjançant l’esquema CustomizationID (és a dir, mitjançant una identificació que descriu el perfil / el context de „Customization“). Això és important perquè demostra: en l’entorn Peppol, les identificacions de perfil i de conformitat són part del processament automàtic i no només „nice to have“.^[Quelle]

Les conseqüències operatives són molt concretes: a més de la comprovació del document s’afegeixen temes de transport. Adreçament, identificadors de participant, denegacions tècniques, comprovants de lliurament — tot això genera patrons d’error específics. Si no classifiqueu aquests errors per separat, al final tot acabarà com a „factura trencada“ a Finance o com a „Peppol falla“ a IT.

Leitweg-ID & Peppol-ID: Per què els identificadors són crítics per a la producció

El guia d’ús del canal d’entrada Peppol per a l’administració federal descriu, per exemple, la formació de la Peppol-ID a partir del prefix 0204 i de la Leitweg-ID per a les dependències federals connectades i situa la Peppol Authority Deutschland a KoSIT.^[Quelle] Això és un context específic (federal). La lliçó transferible per a empreses, però, és clara: els identificadors no són un tema marginal. Pertanyen als Runbooks, als casos de prova i a la configuració — perquè una „ID incorrecta“ en producció bloqueja tant com un „perfil incorrecte“.

Mapa de ponderació: estratègia de comprovació segons benefici, esforç i risc

Una estratègia pràctica separa les comprovacions en etapes. Heu de decidir conscientment quina etapa actuarà com un punt de control estricte (rebut) i quina etapa només generarà una advertència (esclariment). El mapa següent ajuda a comparar les opcions típiques.

Comprovació de factures electròniques: un camí de revisió robust en operació

Si formalitzeu el procés de comprovació perquè sigui localitzable als logs, runbooks i al sistema de tiquets, la pèrdua de fricció posterior es redueix. El camí següent és deliberadament «orientat a l’operació» i és independent que l’entrada arribi per correu electrònic, càrrega, API o Peppol.

1. Registrar l’entrada: canal, marca temporal, IDs remitent/destinatari, metadades tècniques. Aquesta és la vostra pista d’auditoria.
2. Detectar el contenidor: XML pur? ZUGFeRD (PDF/A‑3 amb XML incrustat)? Altres? En híbrids: extreure l’XML i tractar-lo com a objecte de comprovació separat.
3. Determinar perfil i versió: quina variant està present (p. ex. perfil EN‑16931, versió XRechnung, Peppol BIS Billing amb CustomizationID)? Sense aquesta informació, la verificació és en va.
4. Validació d’estructura: comprovació d’esquema/perfil amb la versió del validador i l’estat del conjunt de regles registrats al protocol. El resultat ha de ser reproduïble.
5. Regles semàntiques: avaluar les regles de negoci EN‑16931 i les comprovacions de consistència (sumes/impostos/lògica d’obligatorietat).
6. Regles de negoci internes: conciliació de dades mestres, vinculació amb la comanda, comprovació de duplicats, regles d’aprovació, requisits de comptabilització. Aquestes regles són específiques de l’empresa i sovint canvien amb més freqüència que els estàndards.
7. Dirigir el resultat: reenviar/contabilitzar automàticament, enviar a aclariment o rebutjar – inclosa la classe d’error, una breu justificació i la referència al registre de comprovacions.

El límit d’aquest procés: no determina automàticament quina regla ha de ser «estricta» a la vostra organització. Això és una decisió de gestió entre el rendiment del procés i el risc — i ha d’estar documentada perquè els canvis siguin rastrejables en el futur.

Conseqüències arquitectòniques: servei central de validació o validació al sistema de destinació?

En els projectes sovint apareix una pregunta aparentment menor: «On validem?» En la pràctica, aquesta decisió determina la mantenibilitat i els costos d’explotació.

Validació centralitzada (servei o plataforma d’integració)

La validació s’executa com un servei central: regles homogènies, classes d’errors uniformes, un sol lloc per a les actualitzacions. Això facilita el monitoratge (p. ex., taxa de rebuig per proveïdor/perfil) i simplifica les auditories, perquè els resultats de la comprovació s’emmagatzemen de manera consistent.

El preu: cal operar un component addicional. Alta disponibilitat, finestres de manteniment, versionat i rollback per a les actualitzacions de regles es converteixen en obligació. A canvi, obteniu control.

Validació descentralitzada (plugins ERP/DMS, clients)

Aquí la comprovació es fa en diversos sistemes. Això pot semblar atractiu a curt termini («l’ERP ja ho pot fer»), però sovint condueix a deriva: versions diferents del validador, missatges d’error diferents, excepcions diferents. I això precisament és nociu per a l’estandardització i el suport.

Per a la direcció d’IT és útil una regla empírica: si hi ha diversos canals d’entrada i diversos sistemes de destinació en joc, un servei de comprovació central sol ser la decisió més robusta a llarg termini. Si només hi ha un camí clar (un ERP, una entrada), la validació descentralitzada pot ser acceptable — però llavors el versionat s’ha de regular igualment de manera clara.

Què realment fa perdre temps en els projectes a l’hora de validar

Tècnicament, la lectura d’XML rarament és el problema. El temps i el risc apareixen als punts de contacte:

• Varietat de perfils i versions: Sense transparència sobre quins socis envien quins perfils, cada llançament serà en pilot a vista. La telemetria (perfil/version per entrada) no és un luxe, sinó un instrument de control.
• Traducció d’errors: Les sortides del validador sovint són massa crues per als departaments especialitzats o els proveïdors. Cal una assignació a categories comprensibles i opcions d’actuació.
• Dades mestres i processos: Les factures estructurades fan visibles els problemes de dades mestres (assignació de creditor absent, números de comanda inconsistents). Això és positiu, però genera inicialment més casos d’aclariment.
• Cadena de comprovants i arxiu: Per a la traçabilitat no n’hi ha prou amb «fitxer arxivat». Són determinants: l’original (PDF/XML), el resultat de la comprovació, la versió del conjunt de regles, el moment i la relació amb el procés de negoci (aprovació, comptabilització).

Desplegament sense ruptura del procés: onades, fallback i criteris mesurables

Un desplegament estable s’aconsegueix si no activeu tot en producció alhora. Ha demostrat ser eficaç una lògica per onades:

• Pilot: pocs proveïdors i tipus de document, registre molt detallat, revisió diària de les classes d’errors més freqüents.
• Estabilització: afinar les regles, però amb finestres de canvi i comunicació clara. Aclareu de manera dirigida els errors recurrents amb patrons conjuntament amb compres/proveïdors.
• Escalat: transferir el monitoratge a l’operació regular (quota de rebuig, temps de resolució, principals incompliments de regles, percentatge manual).

Planifiqueu també l‘operació d’emergència. Si una actualització de regles bloqueja de sobte moltes factures, necessiteu un fallback controlat (p. ex. mode d’alerta temporal en lloc de rebuig ferm) — amb decisió documentada i posterior revisió. Això no és un «suavitzant», sinó un fre operatiu contra parades incontrolades.

Tres malentesos típics que cal aclarir aviat

1) «ZUGFeRD és com abans un PDF.» En el procés compta la XML incrustada. El PDF és útil per a les persones, però no substitueix la comprovació automàtica. Si PDF i XML difereixen, cal que quedi clar quina font preval en el procés.

2) «Peppol fa automàticament que tot sigui conforme.» Peppol ajuda en l’intercanvi i la interoperabilitat. La conformitat s’assoleix només amb continguts correctes i perfils adequats. L’entrega no és el mateix que la validació.

3) «Si el validador marca verd, es pot comptabilitzar.» La conformitat amb l’estàndard és una base, no una autorització completa del procés. Les regles internes (obligatorietat de comanda, recepció de mercaderies, límits d’aprovació) continuen vigents i s’han de gestionar com una etapa pròpia, en lloc de barrejar-les amb la lògica del validador.

Punt final: Una bona comprovació alleuja la càrrega — si està dissenyada com a procés operatiu

Verificar factures electròniques no és un fi en si mateix. L’utilitat s’obté quan la validació es concep com un sistema operatiu: versionat, observable, amb classes d’error clares i un canal de retorn que no queda atrapat en un embús de tiquets. Així, estàndards com EN 16931, perfils com XRechnung/ZUGFeRD i vies de transport com Peppol deixen de ser obres permanents i passen a ser components dominables de la vostra cadena de processos.

Per a aquest tema també són importants Zugferd Prüfen i Xrechnung Validieren. L’article situa aquests aspectes de manera comprensible i mostra què és rellevant en el dia a dia.

Parlar del projecte o de l’inici de modernització amb Net-Base.