Integrasjon av e-faktura: Peppol, XRechnung, ZUGFeRD og Factur-X i systemer som ikke ble bygget for det

Å kjøpe et e-fakturaprodukt er enkelt. Problemet er nesten aldri produktet. Det er det tolv år gamle ordresystemet som produserer fakturaene, prislogikken ingen har dokumentert, og at fakturanumrene kommer fra en lagret prosedyre skrevet av en som sluttet i 2019.

Vi bygger koblingen mellom det du faktisk kjører og det kravene forutsetter. Strukturert fakturaproduksjon, validering, overføring i nettverket, behandling av innkommende fakturaer og arkivering: bygget inn i systemet du har, ikke i stedet for det.

Kravene, og når de treffer

Europa går fra PDF-fakturaer til strukturerte, maskinlesbare fakturaer land for land, i forkant av EUs pakke VAT in the Digital Age (ViDA), som skal harmonisere det hele. Datoene som styrer prosjektene i dag:

• Tyskland: mottak av strukturerte e-fakturaer har vært obligatorisk siden 1. januar 2025. Utstedelse blir obligatorisk 1. januar 2027 for virksomheter med omsetning over 800 000 EUR, og 1. januar 2028 for alle andre. Formatene i praksis er XRechnung (ren XML) og ZUGFeRD 2.x (hybrid PDF med innebygd XML), begge i samsvar med EN 16931.
• Frankrike: mottak, og utstedelse for store og mellomstore selskaper, fra 1. september 2026; utstedelse for SMB-er fra 1. september 2027. Overføringen går gjennom registrerte plattformer, med Factur-X som det vanlige hybridformatet.
• Belgia: obligatorisk B2B-e-faktura via Peppol siden 1. januar 2026, med e-rapportering etter en femhjørnemodell planlagt fra 2028.
• Polen: KSeF, den nasjonale clearance-plattformen, med eget XML-skjema og egen tidsplan.
• Italia: SdI og FatturaPA, i drift siden 2019 og fortsatt den strengeste clearance-modellen i EU.
• Spania: Verifactu og fakturakravene i Crea y Crece, som rulles ut ved siden av de regionale TicketBAI-systemene.

Selger du inn i flere av disse landene, har du ikke ett prosjekt. Du har én arkitektur og flere landadaptere, og forskjellen på å behandle det slik og ikke gjøre det, er forskjellen på én integrasjon og fem.

Der prosjektene faktisk går galt

Fakturadataene finnes ikke i den formen standarden vil ha. EN 16931 krever felter mange systemer aldri har fanget opp: en ordentlig kjøperreferanse, mva.-oppsummering per sats i stedet for per linje, strukturerte betalingsbetingelser, enhetskoder fra et kontrollert vokabular. Ingeniørarbeidet er å rekonstruere de feltene fra det du har, deterministisk, for hver eneste faktura du kommer til å sende.

Valideringsfeil dukker opp i etterkant. En avvist faktura er en ubetalt faktura. Valideringen må kjøre før overføring, mot gjeldende skjema og gjeldende forretningsregler i landet, og feilene må havne hos et menneske som kan gjøre noe med dem, ikke i en loggfil.

Innkommende er vanskeligere enn utgående. Alle planlegger for å sende fakturaer og glemmer at de fra mottaksdatoen må ta imot strukturerte fakturaer fra hver eneste leverandør, i alle formater som følger standarden, og få dem inn i leverandørreskontroen uten at noen åpner hver enkelt.

Nummerering og idempotens. Gjenforsøk, tidsavbrudd i nettverket og nedetid hos plattformene er normalen. En faktura sendt to ganger under to numre er et skatteproblem, ikke et programvareproblem. Dette må sitte fra starten.

Hva vi bygger

Kartlegging og valg av format

Et kort oppdrag (vanligvis én til to uker) der vi ser på hvordan fakturaene dine faktisk blir til, hvilke krav som treffer deg og når, og hvilke reelle alternativer du har. Leveransen er en skriftlig anbefaling: hvilke formater du trenger, om Peppol-tilknytningen bør gå gjennom en leverandør eller et eget aksesspunkt, hva som må endres i kildesystemet, og hva det koster.

Noen ganger er anbefalingen at et standardprodukt pluss en liten adapter gjør jobben. Det sier vi heller i uke én enn å fakturere deg for seks måneder.

Fakturaproduksjon og mapping

Vi bygger mappinglaget fra kildedataene dine til de nødvendige syntaksene (UBL og CII under EN 16931, XRechnung, ZUGFeRD 2.x, Factur-X, FatturaPA, KSeF XML), med feltavledningene dokumentert slik at både en revisor og økonomiavdelingen din kan følge dem. Der kildesystemet ikke kan levere et obligatorisk felt i det hele tatt, sier vi fra tidlig og designer registreringen i stedet for å finne på en standardverdi.

Validering før overføring

Skjemavalidering, Schematron-forretningsregler og landspesifikke kontroller kjøres før noe forlater huset. Feil rutes til en kø et menneske eier, med en melding om hvilket felt som feilet og hvorfor, ikke en stack trace.

Tilknytning til nettverket

Tilknytning til et Peppol Access Point, enten gjennom en etablert leverandør eller ved å drifte ditt eget, avhengig av volum og hvor mye kontroll du trenger. For land med clearance-modell integrerer vi direkte mot den nasjonale plattformen (KSeF, SdI, det franske PDP-økosystemet), inkludert sertifikat- og autentiseringshåndteringen, som disse plattformene gjør på hver sin måte.

Behandling av innkommende fakturaer

Mottak, validering og normalisering av leverandørfakturaer til én intern representasjon, matchet mot innkjøpsordrer og varemottak der de finnes, og levert inn i arbeidsflyten for leverandørreskontro. Det er som regel her gevinsten i prosjektet ligger, fordi det fjerner manuell tasting ingen noen gang har målt.

Arkivering og revisjonsspor

Etterlevende lagring av det originale strukturerte dokumentet, i en form og i en periode som tilfredsstiller tyske GoBD, italiensk conservazione sostitutiva eller tilsvarende regler der du opererer, med gjenfinningsveien testet, ikke antatt.

Systemer vi integrerer med

SAP ECC og S/4HANA, Microsoft Dynamics 365 og Business Central, Odoo, NetSuite, Sage, Infor, Xero, DATEV-grensesnitt og (oftest) et egenutviklet eller kraftig tilpasset system som er sentralt i driften og ikke kommer til å bli byttet ut på grunn av et regelverkskrav. Vi jobber i .NET, Java, PHP, Python, Node.js og, når det er det som står der, eldre stacker.

Driver du en markedsplass, en abonnementsplattform eller en faktureringsmotor som utsteder fakturaer programmatisk i volum, er det akkurat det tilfellet vi er bygget for: fakturaen lages av koden din, altså må etterlevelsen bo i koden din.

Hva dette ikke er

Vi selger ikke fakturaprogramvare og vi er ikke et regnskapssystem. Er du en liten bedrift som leter etter et verktøy som lager fakturaer i riktig format, så kjøp et: DATEV, sevDesk, Lexware og et dusin andre gjør dette godt og koster en brøkdel av et integrasjonsprosjekt.

Kom til oss når fakturaen produseres av et system du allerede eier, når flere lands regler må leve side om side, eller når volumet gjør at dette må gå uten at noen ser på.

Slik kjøres oppdragene

Kartlegging, én til to uker, fastpris, som ender i en skriftlig anbefaling og en kostnadsberegnet plan.

Bygging, typisk seks til tolv uker for første land, avhengig av hvor rene kildedataene er. Vi jobber i ditt repository, med din branch-strategi, sammen med teamet ditt, og vi etterlater tester.

Pilot, med ekte fakturaer til et lite utvalg motparter parallelt med den eksisterende prosessen, til feilraten er der den skal være.

Cutover og støtte, med feilkøen overvåket og noen som er ansvarlig for den, gjennom første månedsavslutning og første mva.-innlevering, som er da spørsmålene som betyr noe faktisk dukker opp.

Standarder vi arbeider etter

EN 16931 og syntaksbindingene (UBL 2.1, UN/CEFACT CII), Peppol BIS Billing 3.0 og Peppol-infrastrukturen, XRechnung og KoSIT-validatoren, ZUGFeRD 2.x og Factur-X-profilene, FatturaPA, KSeF, og ViDA-forslagene som former det som kommer etter 2030.

Ofte stilte spørsmål

Når gjelder den tyske e-fakturaplikten for oss, nøyaktig?

Mottak har gjeldt for alle tyske virksomheter siden 1. januar 2025. Utstedelse gjelder fra 1. januar 2027 dersom omsetningen året før oversteg 800 000 EUR, og fra 1. januar 2028 ellers. Plikten omfatter innenlandske B2B-transaksjoner; behandlingen av grensekryssende fakturering og B2C er en annen, og bør avklares med skatterådgiveren din.

Hva er forskjellen på XRechnung og ZUGFeRD?

XRechnung er ren XML, definert av tysk offentlig sektor og obligatorisk for fakturaer til offentlige myndigheter. ZUGFeRD 2.x er hybrid: et PDF/A-3-dokument med de samme strukturerte dataene innebygd, slik at et menneske kan lese PDF-en og en maskin kan lese XML-en. Begge er i samsvar med EN 16931. Kommersiell B2B-praksis i Tyskland heller mot ZUGFeRD, og mange kjøpere tar imot begge deler.

Trenger vi vårt eget Peppol Access Point?

Som regel ikke. De fleste kobler seg til gjennom en eksisterende aksesspunktleverandør, noe som er billigere og raskere. Eget aksesspunkt gir mening ved høyt volum, når du trenger kontroll over transportlaget, eller når du selv leverer faktureringstjenester til andre.

Kan dere jobbe med e-fakturaleverandøren vi allerede har?

Ja, og ofte er det den riktige arbeidsdelingen: leverandøren håndterer overføring og nettverksmedlemskap, vi bygger alt mellom systemet ditt og API-et deres, mapping, validering, gjenforsøk, feilhåndtering og avstemming.

Hva skjer med fakturaer som feiler valideringen?

De havner i en kø med en lesbar forklaring på hvilket felt som brøt hvilken regel. Den køen designer vi bevisst, for i de første månedene etter produksjonssetting er den den mest brukte delen av systemet, og en dårlig kø gjør et etterlevelsesprosjekt om til en permanent manuell prosess.

Hvordan unngår dere å sende samme faktura to ganger?

En stabil idempotensnøkkel avledet av fakturaens identitet, båret med gjennom hvert gjenforsøk, pluss en overføringslogg som er fasiten på hva som er sendt. Hvert gjenforsøk gjenbruker den opprinnelige identifikatoren i stedet for å lage en ny.

Kom i gang

Fortell oss hvilke land du fakturerer inn i, omtrent hvor mange fakturaer i måneden, og hva som produserer dem i dag. Vi sier deg hvilke krav som treffer deg, i hvilken rekkefølge, og om dette er en kobling eller et prosjekt.

Kontakt oss for å avtale en kartlegging av e-fakturaberedskap.

Relaterte tjenester

• EU-markedsinngang utvikling: resten av regelverksstakken for salg inn i Europa
• ERP-modernisering og exit fra SAP ECC: når fakturakravet lander midt i en migrering
• Vedlikehold av eldre systemkode: for systemet som produserer fakturaene