E-fakturering: Peppol, XRechnung, ZUGFeRD og Factur-X i systemer, der aldrig blev bygget til det
At købe et e-faktureringsprodukt er nemt. Problemet er næsten aldrig produktet. Det er det tolv år gamle ordresystem, der producerer fakturaerne, prislogikken ingen har dokumenteret, og at fakturanumrene kommer fra en stored procedure, som en medarbejder skrev, inden vedkommende sagde op i 2019.
Vi bygger forbindelsen mellem det, I faktisk kører, og det, lovkravet forlanger. Generering af strukturerede fakturaer, validering, forsendelse over nettet, indgående behandling og arkivering, koblet ind i jeres eksisterende system i stedet for at erstatte det.
Kravene, og hvornår de bider
Europa går fra PDF-fakturaer til strukturerede, maskinlæsbare fakturaer land for land, forud for EU's VAT in the Digital Age (ViDA), der skal harmonisere det hele. De datoer, der driver projekterne lige nu:
- Tyskland: det har været obligatorisk at kunne modtage strukturerede e-fakturaer siden 1. januar 2025. Udstedelse bliver obligatorisk 1. januar 2027 for virksomheder med en omsætning over 800.000 EUR og 1. januar 2028 for alle andre. Formaterne i praksis er XRechnung (ren XML) og ZUGFeRD 2.x (en hybrid-PDF med indlejret XML), begge i overensstemmelse med EN 16931.
- Frankrig: modtagelse, og udstedelse for store og mellemstore virksomheder, fra 1. september 2026; udstedelse for SMV'er fra 1. september 2027. Transmissionen går gennem registrerede platforme, med Factur-X som det fælles hybridformat.
- Belgien: obligatorisk B2B-e-fakturering via Peppol siden 1. januar 2026, med e-rapportering efter en femhjørnemodel planlagt til 2028.
- Polen: KSeF, den nationale clearingplatform, med sit eget XML-skema og sin egen tidsplan.
- Italien: SdI og FatturaPA, i drift siden 2019 og fortsat den strengeste clearingmodel i EU.
- Spanien: Verifactu og fakturakravene i Crea y Crece, der rulles ud sideløbende med de regionale TicketBAI-systemer.
Sælger I ind i flere af dem, har I ikke ét projekt. I har én arkitektur og en række landeadaptere, og forskellen på at gribe det an sådan og lade være er forskellen på én integration og fem.
Hvor projekterne reelt går galt
Fakturadataene findes ikke i den form, standarden vil have. EN 16931 kræver felter, mange systemer aldrig har registreret: en ordentlig køberreference, momsopdeling pr. sats frem for pr. linje, strukturerede betalingsbetingelser, enhedskoder fra en fast kodeliste. Ingeniørarbejdet er at rekonstruere de felter deterministisk ud fra det, I har, for hver eneste faktura I nogensinde kommer til at udstede.
Valideringsfejl dukker op bagefter. En afvist faktura er en ubetalt faktura. Validering skal køre før forsendelse, mod det gældende skema og de gældende nationale forretningsregler, og fejlene skal ende hos et menneske, der kan gøre noget ved dem, i stedet for i en logfil.
Indgående er sværere end udgående. Alle planlægger for at udstede fakturaer og glemmer, at de fra modtagedatoen skal kunne tage imod strukturerede fakturaer fra samtlige leverandører, i ethvert konformt format, og få dem ind i kreditorbogholderiet, uden at nogen åbner dem én for én.
Nummerering og idempotens. Genforsøg, netværkstimeouts og nedbrud hos platformene er hverdag. En faktura, der sendes to gange under to numre, er et momsproblem, ikke et softwareproblem. Det skal være rigtigt fra starten.
Det, vi bygger
Analyse og valg af format
En kort opgave (typisk en til to uger), hvor vi ser på, hvordan jeres fakturaer rent faktisk bliver til, hvilke krav der rammer jer og hvornår, og hvad jeres realistiske muligheder er. Leverancen er en skriftlig anbefaling: hvilke formater I har brug for, om Peppol-adgangen skal gå gennem en udbyder eller jeres eget access point, hvad der skal ændres i kildesystemet, og hvad det koster.
Nogle gange lyder anbefalingen, at et standardprodukt plus en lille adapter gør arbejdet. Det siger vi hellere i uge et end at fakturere jer for et halvt år.
Fakturagenerering og mapning
Vi bygger mapningslaget fra jeres kildedata til de krævede syntakser (UBL og CII under EN 16931, XRechnung, ZUGFeRD 2.x, Factur-X, FatturaPA, KSeF-XML), med feltafledningerne dokumenteret, så både en revisor og jeres økonomiafdeling kan følge dem. Hvor kildesystemet slet ikke kan levere et obligatorisk felt, siger vi det tidligt og designer registreringen frem for at opfinde en defaultværdi.
Validering før forsendelse
Skemavalidering, Schematron-forretningsregler og landespecifikke kontroller kører, før noget forlader huset. Fejl havner i en kø, som et menneske ejer, med en besked om hvilket felt der fejlede hvilken regel, ikke et stacktrace.
Netværksforbindelse
Tilslutning til et Peppol Access Point, enten gennem en etableret udbyder eller ved at køre jeres eget, afhængigt af volumen og hvor meget kontrol I har brug for. I lande med clearingmodel integrerer vi direkte til den nationale platform (KSeF, SdI, det franske PDP-økosystem), inklusive den certifikat- og autentificeringshåndtering, som platformene alle gør på hver sin måde.
Indgående behandling
Modtagelse, validering og normalisering af leverandørfakturaer til én intern repræsentation, matchet mod indkøbsordrer og varemodtagelser hvor de findes, og leveret ind i jeres kreditorworkflow. Det er typisk her, projektet tjener sig hjem, fordi det fjerner en manuel indtastning, ingen nogensinde har målt.
Arkivering og revisionsspor
Compliant opbevaring af det oprindelige strukturerede dokument, i en form og i en periode der lever op til tyske GoBD, italiensk conservazione sostitutiva eller de tilsvarende regler dér, hvor I opererer, med søgevejen testet frem for antaget.
Systemer, vi integrerer med
SAP ECC og S/4HANA, Microsoft Dynamics 365 og Business Central, Odoo, NetSuite, Sage, Infor, Xero, DATEV-grænseflader og (oftest) et egenudviklet eller kraftigt tilpasset system, som er helt centralt for driften, og som ikke bliver udskiftet på grund af et lovkrav. Vi arbejder i .NET, Java, PHP, Python, Node.js og, når det er dét der står foran os, ældre stakke.
Kører I en markedsplads, en abonnementsplatform eller en faktureringsmotor, der udsteder fakturaer programmatisk i stort antal, er det præcis den situation, vi er bygget til: fakturaen bliver dannet af jeres kode, så compliance er nødt til at bo i jeres kode.
Hvad det ikke er
Vi sælger ikke faktureringssoftware, og vi er ikke et økonomisystem. Er I en mindre virksomhed, der leder efter et værktøj, som laver compliant fakturaer, så køb et: DATEV, sevDesk, Lexware og et dusin andre gør det godt og koster en brøkdel af et integrationsprojekt.
Kom til os, når fakturaen bliver dannet af et system, I allerede ejer, når flere landes regler skal fungere side om side, eller når volumen betyder, at det her skal køre, uden at nogen holder øje.
Sådan forløber et samarbejde
Analyse, en til to uger, fast pris, der ender i en skriftlig anbefaling og en prissat plan.
Udvikling, typisk seks til tolv uger for det første land, afhængigt af hvor rene kildedataene er. Vi arbejder i jeres repository, efter jeres branchstrategi, sammen med jeres team, og vi efterlader tests.
Pilot, hvor rigtige fakturaer sendes til et lille udsnit af modparter parallelt med den eksisterende proces, indtil fejlprocenten er, hvor den skal være.
Cutover og support, hvor fejlkøen bliver overvåget, og nogen er ansvarlig for den, gennem den første månedsafslutning og den første momsangivelse. Det er dér, de spørgsmål der betyder noget, dukker op.
Standarder, vi arbejder efter
EN 16931 og bindingerne til syntakserne (UBL 2.1, UN/CEFACT CII), Peppol BIS Billing 3.0 og Peppol-transportinfrastrukturen, XRechnung og KoSIT-validatoren, ZUGFeRD 2.x- og Factur-X-profilerne, FatturaPA, KSeF og de ViDA-forslag, der former det, som kommer efter 2030.
Ofte stillede spørgsmål
Hvornår gælder det tyske e-faktureringskrav præcis for os?
Modtagelse har været et krav for alle tyske virksomheder siden 1. januar 2025. Udstedelse gælder fra 1. januar 2027, hvis omsætningen året før oversteg 800.000 EUR, og fra 1. januar 2028 ellers. Kravet omfatter indenlandske B2B-transaktioner; behandlingen af grænseoverskridende fakturering og B2C-fakturering er anderledes og er værd at få bekræftet hos jeres skatterådgiver.
Hvad er forskellen på XRechnung og ZUGFeRD?
XRechnung er ren XML, defineret af den tyske offentlige sektor og obligatorisk for fakturaer til offentlige myndigheder. ZUGFeRD 2.x er en hybrid: et PDF/A-3-dokument med de samme strukturerede data indlejret, så et menneske kan læse PDF'en, og en maskine kan læse XML'en. Begge er i overensstemmelse med EN 16931. Kommerciel B2B-praksis i Tyskland hælder mod ZUGFeRD; mange købere tager imod begge.
Har vi brug for vores eget Peppol Access Point?
Som regel ikke. De fleste virksomheder kobler sig på gennem en eksisterende access point-udbyder, hvilket er billigere og hurtigere. Sit eget giver mening ved stor volumen, når man har brug for kontrol over transportlaget, eller når man leverer faktureringsydelser til andre.
Kan I arbejde sammen med vores nuværende e-faktureringsleverandør?
Ja, og det er ofte den rigtige model: leverandøren står for transmission og netværksmedlemskab, og vi bygger alt mellem jeres system og deres API, mapningen, valideringen, genforsøgene, fejlhåndteringen og afstemningen.
Hvad sker der med fakturaer, der fejler validering?
De ryger i en kø med en læsbar forklaring på, hvilket felt der fejlede hvilken regel. Den kø designer vi bevidst, for i de første måneder efter go-live er den den mest brugte del af systemet, og en dårlig én laver et complianceprojekt om til en permanent manuel proces.
Hvordan undgår I at sende den samme faktura to gange?
En stabil idempotensnøgle afledt af fakturaens identitet, båret med gennem hvert genforsøg, plus en forsendelseslog, der er den autoritative kilde til, hvad der er sendt. Ethvert genforsøg genbruger den oprindelige identifikator i stedet for at danne en ny.
Kom i gang
Fortæl os, hvilke lande I fakturerer ind i, cirka hvor mange fakturaer om måneden, og hvad der producerer dem i dag. Så siger vi, hvilke krav der rammer jer, i hvilken rækkefølge, og om det her er en konnektor eller et projekt.
Kontakt os for at booke en readiness-analyse for e-fakturering.
Relaterede ydelser
- EU market entry development: resten af regelstakken for salg ind i Europa
- ERP-modernisering og exit fra SAP ECC: når faktureringskravet lander midt i en migrering
- Vedligeholdelse af legacy-systemer: til systemet, der producerer fakturaerne
Klar til at komme i gang med denne ydelse?
Kontakt os