Hvornår de to dage begynder at tælle

Vores mål er den første gyldige testfaktura inden for to arbejdsdage. Når folk hører det, spørger de, hvornår de to dage begynder. Det ærlige svar er: når syv ting er på plads. Denne tjekliste til e-⁠fakturering er de syv ting. Før de er på plads, kan ingen love en dato, heller ikke vi, fordi det arbejde, der tager tid, venter på noget, som kun du kan levere.

Her gennemgår vi de syv punkter: hvorfor hvert af dem betyder noget, hvem der har ansvaret for det, og hvor projekter typisk går i stå. Sæt flueben ved dem nedenfor, mens du læser. Uret starter, når alle syv har fået et flueben.

• Et repræsentativt udvalg af fakturaer, der dækker alle varianter, opgaven omfatter
• Fungerende adgang til kilden eller en stabil overførsel via fil eller API
• Adgangsoplysninger, certifikater og skatteyderens autorisation til test, udstedt til dig
• Ruten valgt, med et aktivt testmiljø
• En teknisk ansvarlig på din side, som er tilgængelig i perioden
• Skriftlige beslutninger om momskoder, fritagelser, betalingsoplysninger og identifikatorer
• En webhook-URL til den returnerede status

0 / 7 på plads. Uret er ikke startet endnu.

Hvorfor uret først starter, når forudsætningerne er på plads

En underskrift fortæller os, at du vil have arbejdet udført. Den giver os ikke de fakturaer, den adgang eller de beslutninger, som arbejdet kræver. Hvis vi begyndte at tælle på underskriftsdagen, ville de to dage gå med at vente på en eksport eller et testlogin, og målet ville ikke betyde noget.

Derfor er målet i stedet knyttet til forudsætningerne. De udgør en kort liste, listen er den samme for alle ruter, og hvert punkt har én ansvarlig. Når det sidste punkt er på plads, har vi alt, hvad vi skal bruge for at mappe, validere og sende en testfaktura, og så er det vores opgave at holde de to arbejdsdage. Ordlisten kalder den samme liste for readiness package.

Det gør det også let at tale om forsinkelser. Hvis testfakturaen er forsinket, er spørgsmålet ikke »hvem er langsom?«, men »hvilket punkt mangler, og hvem har ansvaret for det?«. Begge parter kan se svaret.

Tjekliste til e-⁠fakturering, punkt for punkt

1. Et repræsentativt udvalg af fakturaer

Vi har brug for rigtige fakturaer fra dit ERP, der dækker alle varianter, opgaven omfatter: almindelige fakturaer, kreditnotaer og de usædvanlige, for eksempel linjer med omvendt betalingspligt, fakturaer i udenlandsk valuta eller fakturaer, der henviser til en ordre. Mappingen bygges ud fra dem. En variant, vi aldrig ser, er en variant, vi ikke kan teste.

Ansvarlig: dit team. Det typiske hul er et udvalg, der kun rummer de lette tilfælde.

2. Fungerende adgang til kilden

Vi læser fakturadataene der, hvor dit ERP danner dem. Det kan være fungerende adgang til kildesystemet eller en stabil overførsel: den samme fil eller det samme API-kald hver gang, med testdata i. Et regneark, der er lavet i hånden én gang, tæller ikke, fordi produktionen ikke vil se sådan ud.

Ansvarlig: dit team. Det typiske hul er en eksport, der stadig ændrer sig fra uge til uge.

3. Adgangsoplysninger, certifikater og skatteyderens autorisation til test, udstedt til dig

Hver rute har sin egen måde at lukke en virksomhed ind på: et token, et certifikat, en autorisation på en skatteportal, en konto hos et adgangspunkt eller en platform. De udstedes til din virksomhed, i dit navn, på den rute, du har valgt.

Ansvarlig: dit team. Det typiske hul er en anmodning, der stadig ligger hos platformen.

4. Ruten valgt, med et aktivt testmiljø

Ruten er den vej, din faktura kommer frem til køberen ad i ét land: Peppol, en fransk platform, KSeF, RO e-⁠Factura og så videre. Du vælger den, og dens testmiljø skal være slået til for din virksomhed. Vi forbinder den.

Ansvarlig: du vælger, vi forbinder. Det typiske hul er et testmiljø, der findes på papiret, men endnu ikke er aktivt.

5. En teknisk ansvarlig på din side, som er tilgængelig i perioden

Nogen på din side skal svare på spørgsmål, mens vi arbejder: hvor et felt kommer fra, hvorfor en kode ser ud, som den gør, og om en testfaktura må sendes. To arbejdsdage holder ikke til tre dages ventetid på et svar.

Ansvarlig: dit team. Det typiske hul er et navn uden afsat tid.

6. Skriftlige beslutninger om momskoder, fritagelser, betalingsoplysninger og identifikatorer

Nogle spørgsmål er ikke tekniske. Hvilken momskategori gælder for denne linje? Hvilken fritagelsesgrund skal stå på den anden? Hvilken identifikator bruger vi for sælger og køber? Det er skattemæssige beslutninger, og de tilhører dig og din revisor. Vi skal have dem på skrift, så mappingen følger dine beslutninger og ikke vores gæt.

Ansvarlig: dit team sammen med din revisor. Det typiske hul er en beslutning, der blev truffet på et møde og aldrig skrevet ned.

7. En webhook-URL til den returnerede status

Hver rute svarer forskelligt. Vi omsætter hvert svar til én hændelse, som dit ERP kan læse, og rutens egen kode følger med. Til det skal vi have et sted at sende den hen: en webhook-URL på din side eller en aftale om, at du læser status via API’et.

Ansvarlig: dit team. Det typiske hul er en URL, som ingen på ERP-siden lytter på endnu.

Hvad der sker i de to arbejdsdage

Når det syvende punkt er på plads, kører arbejdet i en fast rækkefølge. Vi bygger mappingen fra dine fakturaer til EN 16931 [1] og landets format, tjekker hver variant mod de officielle regler og sender fakturaer gennem rutens testmiljø. Status kommer tilbage til dig på samme måde, som den vil gøre i produktion. Tryk på afspil for at følge én faktura hele vejen.

▶Afspil

1. 01ERP-eksport
2. 02Mapping
3. 03Validering
4. 04Rute
5. 05Køber og skatteplatform

↺Status kommer tilbage via webhook eller API: accepteret, afvist med en kode eller afslået af køberen.

ERP-eksportERP-data

Dit ERP danner fakturadataene: en rapport, en fil eller et API-kald.

Hvad der kan gå galtEt felt mangler i eksporten, for eksempel køberens momsnummer.

Målet er den første gyldige testfaktura inden for de to arbejdsdage. En gyldig testfaktura er en faktura, som rutens testmiljø accepterer. Det er det første bevis på, at dine data, vores mapping og ruten stemmer overens med hinanden.

Hvor de syv punkter passer ind i de seks trin

Listen over forudsætninger er ikke en separat proces. Den er den del af vores seks trin, som kun du kan sætte i gang. Sådan fordeler arbejdet sig, når opgavebeskrivelsen er underskrevet:

Trin	Det gør du	Det gør vi
Afgrænsning	Kommer med opgaven og enhedens oplysninger	Tjekker den mod standardpakken
Mapping	Giver adgang og repræsentative fakturaer	Bygger mappingtabellen
Validering	Beslutter momskoder og identifikatorer	Kører regelsættene og retter mappingen
Test	Skaffer adgangsoplysningerne til test	Sender, bekræfter og mapper status
Go-live	Kører din accepttest og godkender	Overvåger de første fakturaer i produktion
Overvågning	Retter data ved kilden, når vi beder om det	Sortering, rettelser i mappingen og månedsrapporten

Punkt 1, 2 og 6 bruges i trinnene mapping og validering. Punkt 3, 4 og 7 bruges i testtrinnet. Punkt 5, den tekniske ansvarlige, holder dem alle i gang.

Hvad punkt 3 og 4 betyder på tre ruter

Ordene på listen er de samme overalt, men arbejdet bag dem afhænger af ruten: et KSeF-token i Polen [2], et Peppol ID i Belgien, en registrering hos en Plateforme Agréée i Frankrig [3].

• KSeFPL

  Punkt 3: adgang, udstedt til dig

  Et KSeF-token eller -certifikat med tilladelse til at udstede fakturaer for dit NIP

  Punkt 4: testmiljøet

  KSeF’s testmiljø

  Vær opmærksom på

  Et token uden tilladelsen InvoiceWrite kan ikke åbne en afsendelsessession, så KSeF ser aldrig fakturaen

• PeppolBE

  Punkt 3: adgang, udstedt til dig

  En konto hos et certificeret adgangspunkt og det Peppol ID, din virksomhed er registreret under

  Punkt 4: testmiljøet

  Dit adgangspunkts testopsætning

  Vær opmærksom på

  Uden dit Peppol ID som sælgers elektroniske adresse afviser en Peppol-regel fakturaen

• Plateforme AgrééeFR

  Punkt 3: adgang, udstedt til dig

  Din registrering hos platformen, med dit SIREN aktivt i det nationale register

  Punkt 4: testmiljøet

  Platformens testmiljø, adskilt fra produktion

  Vær opmærksom på

  Test og produktion er adskilt: at være sat op i det ene er ikke det samme som at være sat op i det andet

To af de tre fejl stopper en test, før nogen køber ser den. KSeF åbner ikke en afsendelsessession for et token uden tilladelsen InvoiceWrite [4], og på Peppol afviser reglen PEPPOL-⁠EN16931-⁠R020 fakturaen, før den bliver sendt af sted [5]. Derfor står begge punkter på listen over forudsætninger, før uret starter, og ikke inden for de to arbejdsdage.

I Frankrig virker det nationale register i begge retninger. En virksomhed, der ikke har valgt en modtageplatform, mangler i registeret, og fakturaer adresseret til den virksomhed kan ikke leveres [6].

Hvad uret ikke dækker

Nogle trin ligger uden for de to dage, fordi ingen af parterne styrer dem. Figuren viser, hvor de ligger i forhold til uret.

ForudsætningerI dit tempoDe to arbejdsdagePå uretEfter den første gyldige testfakturaNår du godkender

Dit teamDe syv punkter på listenSvarer på spørgsmål i periodenAccepttest og godkendelse

EurInvoiceForbinder den rute, du har valgtMapper, validerer og sender testfakturaerOvervåger de første fakturaer i produktion

1. Uret starter: alle syv punkter på plads
2. Første gyldige testfaktura

Uden for uret

• Onboarding og KYC hos platformen
• Skatteyderens autorisation til produktion
• Tredjeparter, for eksempel en ERP-leverandør, der ændrer en eksport

• Onboarding og KYC hos platformen, som adgangspunktet eller platformen gennemfører i sit eget tempo.
• Skatteyderens autorisation til produktion, som skattemyndigheden giver.
• Din accepttest, som dit team gennemfører og godkender.
• Tredjeparters tilgængelighed, for eksempel en ERP-leverandør, der skal ændre en eksport.

Intet af dette er en grund til at vente med at gå i gang med de syv punkter. De fleste af dem kan køre parallelt med forudsætningerne, og at starte dem tidligt er den bedste måde at holde hele projektet kort på.

Noget arbejde ligger også uden for selve standardpakken. Flere enheder eller lande, indgående flow, e-⁠rapportering, arkivering, arbejde på ERP-grænseflader og platformsgebyrer prissættes separat. Når du ved det fra start, handler målet på to dage kun om én ting: den første gyldige testfaktura.

Når et punkt mangler

Det sker i de fleste projekter, og det er helt i orden. Når et punkt mangler, siger vi, hvilket det er, hvem der har ansvaret for det, og præcis hvad der er brug for. Uret venter. Der går intet tabt ud over tid, og listen over forudsætninger gør det synligt, hvor tiden går hen.

En besked fra os om et manglende punkt lyder sådan her: »Punkt 3 er stadig åbent. Platformen har endnu ikke aktiveret din testkonto. Ansvarlig: dit team. Når den er aktiv, så send os konto-id’et, og uret kan starte.« Kort, konkret og med én ansvarlig.

Hvis et manglende punkt viser sig at ligge hos os, for eksempel integrationen med ruten, siger vi det på samme måde. Listen gælder for os begge, og det er den samme liste, uanset om du køber direkte hos os eller gennem din ERP-partner.

En tjekliste, du kan sende til dit team

Kopiér den ind i en e-⁠mail til den, der har ansvaret for ERP-siden:

1. Et repræsentativt udvalg af anonymiserede fakturaer, alle varianter, opgaven omfatter.
2. Adgang til kilden eller en stabil overførsel via fil eller API med testdata.
3. Adgangsoplysninger, certifikater og skatteyderens autorisation til test for den valgte rute, udstedt til din virksomhed.
4. Ruten valgt, med et aktivt testmiljø.
5. Én teknisk ansvarlig med afsat tid i perioden.
6. Skriftlige beslutninger om momskoder, fritagelser, betalingsoplysninger og identifikatorer.
7. En webhook-URL til den returnerede status.

Når alle syv er klaret, så giv os besked, og de to arbejdsdage begynder.