Peppol-fakturafeil: 10 årsaker og løsninger

Peppol tilbyr en standardisert infrastruktur for utveksling av elektroniske fakturaer og andre forretningsdokumenter. Men standardisering betyr ikke at alle transaksjoner vil fungere automatisk.

En faktura kan mislykkes fordi dataene er ugyldige, mottakeren ikke kan finnes, feil forretningsprosess brukes eller kjøperen avviser den etter levering. Bedrift miljøer, kan den underliggende årsaken ligge hvor som helst mellom ERP, fakturakartlegging, masterdata , Peppol-oppdagelsestjenester og aksesspunkt .

Denne veiledningen forklarer ti vanlige Peppol-fakturafeil. Hver seksjon starter med det praktiske problemet i et enkelt språk og undersøker deretter de relevante tekniske detaljene for Bedrift og ERP-integrasjonsteam.

Teknisk omfang: Vurdert mot Peppol BIS Billing 3.0 versjon 3.0.21 og OpenPeppol eDelivery-spesifikasjonene tilgjengelige i august 2026. Landsspesifikke krav og spesifikasjoner fortsetter å endres.

Før feilsøking, finn ut hvor feilen oppsto.

Disse feilene krever ulike tiltak. Å sende en uendret faktura på nytt vil ikke korrigere ugyldige data. Endring av fakturaen vil ikke hjelpe hvis mottakerens Peppol-registrering er ufullstendig. En vellykket transportkvittering betyr ikke at kjøperen har godkjent fakturaen.

EN Peppol ID fungerer som en nettverksadresse, men det er ikke alltid nok å oppgi riktig organisasjonsnummer. Identifikatoren må bruke riktig skjema og samsvare nøyaktig med identifikatoren som mottakeren er registrert under.

En tilsynelatende liten forskjell – som feil prefiks, en fjernet innledende null eller bruk av et MVA-nummer i stedet for en nasjonal virksomhetsidentifikator – kan hindre Peppol i å finne mottakeren.

Lagre Peppol-identifikatoren som kontrollert masterdata snarere enn fritekst. Identifikasjonsskjemaet og verdien bør holdes separat og valideres før fakturering.

Før sending:

Et selskap kan være til stede i Peppol uten å kunne motta alle typer Peppol-dokumenter.

For eksempel kan en mottaker være registrert for å motta standard Peppol-meldinger. BIS Billing fakturaer, men ikke en bestemt PINT-faktura, bestillingsmelding eller forretningsprosess. Peppol ID er gyldig, men den forespurte mottaksmuligheten er ikke tilgjengelig.

Ikke behandle registrering som et enkelt ja-eller-nei-attributt i ERP-systemet. Det relevante spørsmålet er om mottakeren kan motta den nøyaktige kombinasjonen av dokumenttype og forretningsprosess som sendes.

Integrasjonen din bør:

Selv når fakturaen og Peppol ID er riktige, kan det hende at nettverket midlertidig ser på feil sted.

Dette kan skje når et selskap bytter Peppol-tjenesteleverandør, når gammel rutingsinformasjon forblir mellomlagret eller mens endringer formidles. Avsenderen kan se en feil som antyder at mottakeren ikke finnes, selv om det faktiske problemet gjelder utdatert oppdagelsesinformasjon.

ERP-applikasjoner bør ikke forsøke å reprodusere hele Peppol-oppdagelsesprosessen selv, med mindre dette er en bevisst del av produktarkitekturen. Oppdagelse, sertifikatvalidering, ruting og håndtering av nye forsøk håndteres vanligvis bedre av Peppol-tjenesteleverandøren.

ERP og Bedrift Lagene bør fortsatt sørge for at:

Hver Peppol-faktura angir hvilke regler den følger og hvilken forretningsprosess den tilhører. Hvis disse identifikatorene mangler eller er feil, kan ikke mottakssystemet tolke dokumentet på en sikker måte.

Dette skjer ofte når et ERP-system eksporterer en gammel fakturamal, en konverter setter inn feil verdi, eller en tilordning som er utformet for ett land eller en prosess, brukes på nytt et annet sted.

Profil- og spesifikasjonsidentifikatorer bør kontrolleres sentralt. De bør ikke kunne redigeres av brukere eller rekonstrueres separat i hver ERP-kobling.

For miljøer med flere markeder:

Fakturaen trenger informasjon som forteller kjøperen hvem som bestilte varene eller hvilken bestilling fakturaen tilhører.

Uten denne referansen kan det hende at kjøperen ikke vet hvor fakturaen skal sendes. Peppol krever derfor enten en kjøperreferanse eller en bestillingsreferanse.

Å legge til «N/A» kan få feltet til å se fullstendig ut, men det gir ikke kjøperen brukbar informasjon.

Registrer den nødvendige referansen før fakturaen opprettes. Ikke stol på at kundefordringsteamene reparerer manglende informasjon etter at fakturaen har mislyktes.

En skalerbar prosess bør:

En faktura kan inneholde riktig totalbeløp, men likevel mislykkes fordi mva-informasjonen ikke gir mening.

Valgt momskategori, momssats og fritaksårsak må stemme overens. Ytterligere nasjonale krav kan gjelde avhengig av hvilke land det er snakk om.

Ikke behandle MVA som et formateringsproblem som håndteres av fakturakonverteringsprogrammet. Skattefastsettelse bør skje i riktig ERP- eller skattemotor før fakturaen genereres.

Bedrift kontrollene bør dekke:

En strukturelt gyldig faktura er ikke nødvendigvis basert på riktig juridisk skattebehandling. Usikre skattescenarier bør gjennomgås av en kvalifisert skattespesialist.

Tallene på fakturaen må summere seg i henhold til definerte beregningsregler.

Problemer oppstår ofte når ERP-systemet, skattesystemet og fakturakonverteringssystemet beregner de samme verdiene forskjellig. En forskjell på én cent kan være nok til å forårsake en fatal valideringsfeil.

Bruk én dokumentert beregnings- og avrundingsmodell gjennom hele fakturaprosessen.

Vær spesielt oppmerksom på:

Valider alltid den endelige XML-en som produseres for overføring. Validering av kun ERP-kildedataene vil ikke oppdage feil introdusert av mapping- eller konverteringslaget.

En strukturert faktura er ikke en digital versjon av en papirfaktura. Blanke rader, visuelle skilletegn og vilkårlig tekst skal ikke konverteres til fakturalinjer.

Hvert felt og hver linje har en definert betydning. Bruk av et felt til noe annet kan sende data til kjøperen, men det hindrer pålitelig automatisering.

ERP-tilordninger bør være semantiske snarere enn visuelle. Tilordne informasjon i henhold til hva den betyr, ikke hvor den vises på en gjengitt faktura.

Vanlige kontroller inkluderer:

En PDF-fil eller annen fil kan legges ved en Peppol-faktura, men mottakeren skal ikke måtte åpne den for å forstå eller behandle transaksjonen.

Hvis bestillingsnummeret, betalingsdetaljer, mva-informasjon eller linjebeskrivelser bare finnes i PDF-filen, mister kjøperen mye av automatiseringen som strukturert e-fakturering er ment å gi.

Behandle vedlegg som støttemateriale. Oppbevar nødvendig og driftsmessig viktig informasjon i strukturerte fakturafelt.

Vedlegg kan være passende for:

Bekreft også krav til medietype, filnavn og størrelse. Tjenesteleverandører og mottakssystemer kan pålegge driftsbegrensninger selv om selve filtypen støttes.

«Levert» betyr ikke «godkjent for betaling».

Peppol kan transportere en teknisk gyldig faktura, men kjøperen kan fortsatt bestride eller avvise den fordi prisen er feil, bestillingen ikke samsvarer, varer ikke er mottatt eller feil juridisk enhet ble fakturert.

ERP- og finansbrukere trenger mer enn en sendt/mislykket status. Integrasjonen bør skille mellom:

Svarene skal være knyttet til den opprinnelige fakturaen og presentert på en måte som gjør det mulig for det ansvarlige teamet å handle. Automatiske nye forsøk må ikke opprette dupliserte fakturaer.

Pålitelig e-fakturering krever mer enn å generere gyldig XML. Hele prosessen må håndtere:

Til Bedrift organisasjoner, bør disse funksjonene sentraliseres snarere enn å bygges opp uavhengig i hvert ERP-system, datterselskap eller marked.

For ERP- og plattformpartnere bør Peppol-tilkobling eksponeres som en administrert tjeneste med stabile API-er, tydelige feilkategorier og handlingsrettede svar. Brukere skal ikke trenge å forstå SMP-poster eller Schematron-regler for å korrigere en faktura – men integrasjonen må håndtere dem riktig under.

Qvalia tilbyr full Peppol-tilkobling for bedrifter, ERP-leverandører og programvareplattformer gjennom API-er og filbaserte integrasjoner. Plattformen håndterer strukturert dokumentutveksling, deltakergjenkjenning, validering, svarmeldinger, feilhåndtering og transaksjonssporbarhet.

Utforsk Qvalia Peppol aksesspunkt .