Fejl i Peppol-fakturaer: 10 årsager og løsninger

Peppol tilbyder en standardiseret infrastruktur til udveksling af elektroniske fakturaer og andre forretningsdokumenter. Men standardisering betyder ikke, at alle transaktioner vil fungere automatisk.

En faktura kan blive afvist, fordi oplysningerne er ugyldige, modtageren ikke kan findes, der anvendes en forkert forretningsproces, eller køberen afviser den efter levering. I virksomhedsmiljøer kan den underliggende årsag ligge hvor som helst mellem ERP-systemet, fakturakortlægning, masterdata, Peppol-opdagelsestjenester og adgangspunktet.

Denne vejledning beskriver ti almindelige fejl i Peppol-fakturaer. Hvert afsnit indledes med en beskrivelse af det konkrete problem i et letforståeligt sprog og gennemgår derefter de relevante tekniske detaljer for virksomhedens og ERP-integrationsteams.

Teknisk omfang: Gennemgået i forhold til Peppol- BIS Billing , version 3.0.21, og OpenPeppol eDelivery-specifikationerne, som vil være tilgængelige i august 2026. Landsspecifikke krav og specifikationer ændrer sig løbende.

Inden du går i gang med fejlfinding, skal du fastslå, hvor fejlen er opstået.

Disse fejl kræver forskellige løsninger. At sende en uændret faktura igen vil ikke rette ugyldige data. Det hjælper ikke at ændre fakturaen, hvis modtagerens Peppol-registrering er ufuldstændig. En bekræftelse på, at overførslen er gennemført, betyder ikke, at køberen har godkendt fakturaen.

En » Peppol ID « fungerer som en netværksadresse, men det er ikke altid nok blot at indtaste det rigtige organisationsnummer. Identifikatoren skal følge det korrekte skema og stemme nøjagtigt overens med den identifikator, som modtageren er registreret under.

En tilsyneladende ubetydelig forskel – såsom et forkert præfiks, en fjernet indledende nul eller brug af et momsnummer i stedet for et nationalt virksomhedsidentifikationsnummer – kan forhindre Peppol i at finde modtageren.

Gem Peppol-identifikatoren som kontrolleret masterdata i stedet for som fritekst. Identifikationsskemaet og værdien skal opbevares separat og valideres inden fakturering.

Før afsendelse:

En virksomhed kan være tilknyttet Peppol uden at kunne modtage alle typer Peppol-dokumenter.

En modtager kan for eksempel være registreret til at modtage standard Peppol-fakturaer ( BIS Billing ), men ikke en bestemt PINT-faktura, en bestillingsmeddelelse eller en forretningsproces. Den generelle modtagelseskapacitet ( Peppol ID ) er gyldig, men den ønskede modtagelseskapacitet er ikke tilgængelig.

Du bør ikke betragte registreringen som et simpelt ja-eller-nej-attribut i ERP-systemet. Det afgørende spørgsmål er, om modtageren kan modtage netop den kombination af dokumenttype og forretningsproces, der sendes.

Din integration bør:

Selv når fakturaen og Peppol ID er korrekte, kan netværket midlertidigt søge det forkerte sted.

Dette kan ske, når en virksomhed skifter Peppol-udbyder, når gamle routingoplysninger stadig ligger i cachen, eller mens ændringerne er ved at blive implementeret. Afsenderen kan få vist en fejlmeddelelse, der antyder, at modtageren ikke findes, selvom det egentlige problem skyldes forældede oplysninger om modtageridentifikation.

ERP-applikationer bør ikke selv forsøge at gengive hele Peppol-opdagelsesprocessen, medmindre dette er en bevidst del af produktarkitekturen. Opdagelse, validering af certifikater, routing og håndtering af gentagne forsøg varetages normalt bedst af Peppol-tjenesteudbyderen.

ERP- og virksomhedsteams bør stadig sikre, at:

Hver Peppol-faktura angiver, hvilke regler den følger, og hvilken forretningsproces den hører under. Hvis disse identifikatorer mangler eller er forkerte, kan modtagersystemet ikke fortolke dokumentet på en sikker måde.

Dette sker ofte, når et ERP-system eksporterer en gammel faktura-skabelon, en konverter indsætter en forkert værdi, eller når en tilknytning, der er udformet til et bestemt land eller en bestemt proces, genbruges et andet sted.

Profil- og specifikationsidentifikatorer bør styres centralt. De bør ikke kunne redigeres af brugerne eller oprettes separat i hver enkelt ERP-konnektor.

I miljøer med flere markeder:

Fakturaen skal indeholde oplysninger, der angiver, hvem der har bestilt varerne, eller hvilken indkøbsordre fakturaen vedrører.

Uden denne reference ved køberen muligvis ikke, hvor fakturaen skal sendes hen. Peppol kræver derfor enten en køberreference eller en indkøbsordre-reference.

Hvis man skriver »N/A«, kan feltet måske se ud som om det er udfyldt, men det giver ikke køberen brugbare oplysninger.

Indhent de nødvendige oplysninger, inden fakturaen oprettes. Stol ikke på, at debitorafdelingen kan rette manglende oplysninger, efter at fakturaen er blevet afvist.

En skalerbar proces bør:

En faktura kan indeholde det korrekte samlet beløb, men alligevel blive afvist, fordi momsoplysningerne ikke giver mening.

Den valgte moms-kategori, momssatsen og begrundelsen for fritagelsen skal stemme overens med hinanden. Der kan gælde yderligere nationale krav afhængigt af de pågældende lande.

Moms bør ikke betragtes som et formateringsspørgsmål, der håndteres af fakturakonverteren. Skatteberegningen bør foretages i det relevante ERP-system eller skatteprogram, inden fakturaen udfærdiges.

Virksomhedens kontrolforanstaltninger bør omfatte:

En formelt korrekt faktura er ikke nødvendigvis baseret på den rette juridiske skattebehandling. Usikre skattesituationer bør gennemgås af en kvalificeret skattespecialist.

Tallene på fakturaen skal stemme overens i henhold til de fastlagte beregningsregler.

Der opstår ofte problemer, når ERP-systemet, skatteberegningsmodulet og fakturakonverteren beregner de samme værdier på forskellige måder. En forskel på blot én cent kan være nok til at udløse en alvorlig valideringsfejl.

Brug én dokumenteret beregnings- og afrundingsmodel i hele faktureringsforløbet.

Vær især opmærksom på:

Kontroller altid den endelige XML-fil, der genereres til overførsel. Hvis man kun validerer kildedataene fra ERP-systemet, vil man ikke opdage fejl, der er opstået i forbindelse med mappingen eller konverteringslaget.

En struktureret faktura er ikke en digital version af en papirfaktura. Tomme rækker, visuelle adskillelser og vilkårlig tekst bør ikke konverteres til fakturalinjer.

Hvert felt og hver linje har en fastlagt betydning. Hvis man bruger et felt til noget andet, kan det godt være, at dataene videregives til køberen, men det forhindrer en pålidelig automatisering.

ERP-tilknytninger bør være semantiske snarere end visuelle. Tilknyt oplysningerne ud fra deres betydning, ikke ud fra hvor de vises på en udskrevet faktura.

Blandt de almindelige kontrolforanstaltninger kan nævnes:

Der kan vedhæftes en PDF-fil eller en anden fil til en Peppol-faktura, men modtageren bør ikke være nødt til at åbne den for at forstå eller behandle transaktionen.

Hvis ordrenummeret, betalingsoplysningerne, momsoplysningerne eller varelinjebeskrivelserne kun findes i PDF-filen, går køberen glip af en stor del af den automatisering, som struktureret e-fakturering er beregnet til at give.

Betragt vedhæftede filer som supplerende materiale. Placer de nødvendige og driftsmæssigt vigtige oplysninger i de strukturerede fakturafelter.

Vedhæftede filer kan være relevante i følgende tilfælde:

Kontroller også kravene til medietype, filnavn og filstørrelse. Tjenesteudbydere og modtagende systemer kan pålægge driftsmæssige begrænsninger, selvom selve filtypen understøttes.

»Leveret« betyder ikke »godkendt til betaling«.

Peppol kan godt formidle en teknisk gyldig faktura, men køberen kan stadig stille spørgsmål til den eller afvise den, fordi prisen er forkert, indkøbsordren ikke stemmer overens, varerne ikke er modtaget, eller fordi fakturaen er udstedt til den forkerte juridiske enhed.

ERP- og økonomibrugere har brug for mere end blot en status som »sendt« eller »mislykket«. Integrationen bør skelne mellem:

Svarene skal knyttes til den oprindelige faktura og præsenteres på en måde, der gør det muligt for det ansvarlige team at handle. Automatiske gentagelser må ikke medføre, at der oprettes dubletter af fakturaer.

Pålidelig e-fakturering kræver mere end blot at generere gyldig XML. Hele processen skal omfatte:

For store virksomheder bør disse funktioner centraliseres i stedet for at blive udviklet hver for sig i hvert ERP-system, hvert datterselskab eller hvert marked.

For ERP- og platformspartnere bør Peppol-tilkoblingen tilbydes som en administreret tjeneste med stabile API’er, klare fejlkategorier og konkrete svar. Brugerne bør ikke være nødt til at forstå SMP-poster eller Schematron-regler for at rette en faktura – men integrationen skal håndtere dem korrekt i baggrunden.

Qvalia tilbyder fuld Peppol-tilkobling til virksomheder, ERP-udbydere og softwareplatforme via API’er og filbaserede integrationer. Platformen håndterer udveksling af strukturerede dokumenter, identifikation af deltagere, validering, svarmeddelelser, fejlhåndtering og sporbarhed af transaktioner.

Udforsk Qvalia Peppol-adgangspunktet.