E-faktura i Frankrike for PME: slik kobler du ditt eget faktureringssystem til før 1. september 2027

Siden 1. september 2026 har alle selskaper i Frankrike som omfattes av reformen, måttet kunne motta elektroniske fakturaer gjennom en plateforme agréée, en godkjent plattform. Store selskaper og ETI har i tillegg måttet utstede fakturaer på den måten og levere e-rapportering. Det franske skattenettstedet beskriver nå reformen som «effective depuis le 1er septembre 2026».

Den andre bølgen kommer 1. september 2027. Fra den datoen må PME, TPE og micro-entreprises utstede B2B-fakturaene sine elektronisk gjennom en godkjent plattform og starte med e-rapportering: å sende myndighetene data om salg til forbrukere, om internasjonale transaksjoner og, for tjenester, om mottatte betalinger.

Kommer fakturaene dine fra en utbredt pakke som Sage, Cegid eller Pennylane, kommer koblingen til en godkjent plattform fra leverandøren, som enten er en slik plattform selv eller samarbeider med en. Din del er å velge plattform og rydde i kundedataene.

Denne artikkelen er for det andre tilfellet: fakturaer som lages av din egen faktureringsprogramvare, et tilpasset ERP-system eller plattformens egen kode. Der må koblingen bygges. Elleve måneder holder hvis du starter nå.

Kalenderen, og hvilken bølge du hører til

DGFiPs praktiske veiledning for oppstarten av e-faktura fastsetter datoene:

• 1. september 2026: alle selskaper som omfattes, må kunne motta e-fakturaer; store selskaper (grandes entreprises) og ETI må i tillegg utstede dem og levere e-rapportering.
• 1. september 2027: PME, TPE og micro-entreprises må utstede og levere e-rapportering.

Størrelsen vurderes per juridisk enhet (per SIREN) per 1. januar 2025, ut fra det siste regnskapsåret som ble avsluttet før den datoen. Ifølge de offisielle spørsmålene og svarene har en PME færre enn 250 ansatte og enten en omsetning på inntil 50 millioner euro eller en balansesum på inntil 43 millioner euro. Over den grensen var datoen din i 2026.

Én felle. De eksterne spesifikasjonene (versjon 3.2, 30. april 2026) plasserer enheter som er med i en mva-gruppe (assujetti unique), i bølgen for 2026, uansett størrelse. Gjelder det dere, er dere allerede for sent ute.

Veiledningen avgjør også to spørsmål i din favør. Du kan begynne å utstede elektronisk før fristen din, frivillig. Og en kunde kan ikke bruke reformen til å tvinge deg til å sende e-fakturaer før 1. september 2027, selv om kontraktene deres fortsatt kan bestemme hvordan dere utveksler fakturaer.

Hva en godkjent plattform gjør

En plateforme agréée er en privat aktør som er registrert (immatriculée) av staten. For å komme på den offisielle listen må den dokumentere at den følger skattereglene, at infrastrukturen og dataene er sikre, og at den er teknisk interoperabel.

Spesifikasjonene kaller arkitekturen «Y»-modellen. Systemet ditt sender fakturaen til plattformen din. Plattformen slår opp kjøperen i den sentrale katalogen (annuaire), som driftes av den offentlige faktureringsportalen (PPF), og leverer fakturaen til kjøperens plattform. I tillegg henter plattformen ut de regulatoriske dataene fra fakturaen og sender dem til PPF, som sender dem videre til skattemyndighetene.

Tre konsekvenser for den som bygger integrasjonen:

• Du snakker aldri direkte med staten. Bare godkjente plattformer kan levere fakturaer til mottakere og sende data til PPF. Faktureringssystemet ditt er det spesifikasjonene kaller en solution compatible: det snakker med en plattform, og plattformen gjør resten.
• Du har sannsynligvis allerede en plattform. Du trengte en for mottak fra 1. september 2026. Spør den først hva den tilbyr for utstedelse. Du står fritt til å bruke en annen, men én kontrakt og én integrasjon er enklere.
• Grensesnittet er standardisert. AFNOR-standarden XP Z12-013 definerer API-ene mellom selskapenes systemer og de godkjente plattformene; XP Z12-012 dekker formatene for fakturaer og statuser. Plattformene tilbyr også EDI og portaler, og Peppol knytter plattformene sammen. Spør hva din plattform støtter, før du designer noe.

Offentlige kjøpere blir værende på Chorus Pro, og eksisterende koblinger til Chorus Pro kan beholdes.

Hva systemet ditt må produsere

En plattform kan transportere og konvertere en faktura. Den kan ikke finne opp data systemet ditt aldri hadde.

Et format fra fellesgrunnlaget

Alle godkjente plattformer må støtte tre formater, alle bygget på den europeiske standarden EN 16931: UBL (versjon 2.1), CII (versjon D22B) og Factur-X, en PDF med de strukturerte dataene innebygd. Plattformene kan godta andre; bare disse tre er garantert.

Velg ut fra hva systemet ditt kan produsere på en ren måte, ikke ut fra hva hver kunde foretrekker. En leverandør kan ikke påtvinge en kjøper et format, og kjøperens plattform kan konvertere til kjøperens foretrukne format. Factur-X passer for selskaper der kundene fortsatt vil ha en lesbar PDF; UBL eller CII passer for rene system-til-system-flyter.

Dataene, felt for felt

Myndighetene publiserer en tabell over fakturadataene de mottar, koblet til forretningsbegrepene i EN 16931. Fire opplysninger er nye for de fleste franske fakturaer:

• kundens SIREN (BT-47);
• transaksjonskategorien: varer, tjenester eller begge deler (BT-23);
• valget om å betale mva ved fakturering (TVA sur les débits), der du har valgt det (BT-8);
• den fullstendige leveringsadressen, hvis den er en annen enn kundens fakturaadresse (BT-75 til BT-80).

Resten av de obligatoriske opplysningene er kjente, men må struktureres: ditt SIREN, begge land, et fakturanummer fra en kronologisk og sammenhengende nummerserie, utstedelsesdato, totalbeløp før mva og mva-beløp, valuta og en mva-oppstilling med grunnlag, avgift og sats for hver sats som brukes (BT-116, BT-117, BT-119). Betingede felt omfatter mva-numre, fritaksgrunnen (som VATEX-kode), omvendt avgiftsplikt, selvfakturering, en leveringsdato som avviker fra fakturadatoen, og referansen til den opprinnelige fakturaen på en korrigerende faktura.

Flere felt i den tabellen forventes først fra 1. september 2027: linjedetaljer (varenavn, antall, enhetspris), rabatter og gebyrer på dokumentnivå, leveringsadressen, datoen for den korrigerte fakturaen, merknaden om kontantrabatt og beløpet for miljøavgiften (éco-participation). Fristen i 2027 er også dagen datamodellen blir dypere for alle.

Der egenutviklede systemer som regel faller gjennom:

• Kundeposten har ikke SIREN, eller har et SIRET i SIREN-feltet.
• Transaksjonskategorien er ikke lagret per vare eller tjeneste, så en blandet faktura kan ikke klassifiseres.
• Mva beregnes og avrundes per linje, så oppstillingen per sats stemmer ikke med totalene.
• Kreditnotaer er frittstående dokumenter uten referanse til fakturaen de korrigerer.
• Fakturanumrene har hull, eller gjenbrukes etter en kansellering.

Hver av disse rettes i kildesystemet, ikke i koblingen.

Rutingsdata

Katalogen adresserer et privat selskap på SIREN-nivå som standard, men kan også rute etter SIRET, rutingskode eller suffiks når en kunde vil ha fakturaer per virksomhet eller avdeling. Lagre de riktige identifikatorene per kunde. Når et oppslag feiler, er veiledningens første instruks å kontrollere SIREN, SIRET og den mottakende virksomheten du brukte.

Livssyklusstatuser, begge veier

En faktura har nå en livssyklus, som overføres som statusmeldinger. Fire statuser er obligatoriske og når skattemyndighetene:

Andre, som «mottatt av plattformen», «omtvistet» eller «betaling sendt», er valgfrie.

Systemet ditt må kunne lese statuser, ikke bare sende dem. En avvisning fra plattformen (rejet) er teknisk: feil format, manglende eller inkonsistente data, feil ruting. Du retter og sender på nytt. En avvisning fra kjøperen (refus) må begrunnes, og kan bare bruke de grunnene standarden tillater (en regulatorisk feil plattformen ikke fanget opp, feil mottaker, kontraktsvilkår som ikke er oppfylt), aldri en ren kommersiell uenighet. Utsteder du på nytt etter en slik avvisning, trenger den nye fakturaen et nytt nummer. Spesifikasjonene sier at en faktura som er avvist av kjøperen eller av plattformen, annulleres i regnskapet ditt med en intern kreditnota; veiledningen legger til at du ikke bør lage en slik automatisk hvis du bestrider kjøperens avvisning.

Encaissée er den egenutviklede systemer glemmer. For tjenester, der mva forfaller ved betaling, inneholder denne statusen fakturanummeret, betalingsdatoen og mottatt beløp per mva-sats: det er slik betalingsdata når myndighetene for innenlands B2B. Bankavstemmingen eller kundereskontroen din må altså mate faktureringsintegrasjonen, og det er ofte to systemer som aldri har snakket sammen.

E-rapportering: alt som ikke er en innenlands B2B-faktura

E-faktura dekker salg mellom to mva-registrerte virksomheter etablert i Frankrike. E-rapportering dekker resten, og sendes også gjennom den godkjente plattformen din:

• Salg til ikke-avgiftspliktige (B2C), i Frankrike eller i utlandet: daglige totaler i stedet for enkeltfakturaer, fordelt på kategori (avgiftspliktige varer, avgiftspliktige tjenester, fjernsalg innad i EU, marginordninger), med grunnlag og mva for hver sats.
• Internasjonal B2B: salg til og kjøp fra virksomheter som ikke er etablert i Frankrike, faktura for faktura, med omtrent de samme feltene som en innenlands faktura. Kjøp teller med: kjøper du opplæring fra en tysk leverandør, er det du, den franske kjøperen, som rapporterer.
• Betalingsdata, bare for tjenester, og ikke for transaksjoner med omvendt avgiftsplikt eller for selskaper som har valgt mva ved fakturering: datoen og mottatt beløp per mva-sats.

Rytmen avhenger av mva-ordningen din, ifølge den publiserte tabellen over frekvenser. Under den månedlige régime réel normal sendes transaksjonsdata tre ganger i måneden (fra den 1. til den 10., fra den 11. til den 20. og fra den 21. til månedsslutt), hver med frist ti dager etter perioden, og betalingsdata månedlig før den 10. i påfølgende måned. Under régime simplifié er begge månedlige, med frist mellom den 25. og den 30. i påfølgende måned. Under franchise en base sendes begge annenhver kalendermåned.

Tre innsendinger i måneden er en planlagt jobb, ikke et regneark. Og går B2C-salget ditt gjennom en kasse, en nettbutikk og et faktureringsverktøy, må de daglige totalene komme fra alle tre.

En plan over elleve måneder

Regnet bakover fra 1. september 2027, og med august avskrevet fordi det er august:

1. Oktober 2026: avgrensning. Bekreft størrelseskategorien og om dere er med i en mva-gruppe. List opp hver flyt som lager en faktura eller et salg: innenlands B2B, B2C, internasjonalt, kreditnotaer, forskudd, selvfakturering, offentlig sektor. Spør plattformen dere mottar gjennom, om tilbudet for utstedelse: formater, API-dokumentasjon, testmiljø, statusene den returnerer, e-rapportering.
2. November og desember 2026: data. Kjør felttabellen mot de ekte dataene deres. Legg inn og verifiser SIREN og SIRET på kundepostene, legg transaksjonskategori inn i katalogen, avklar flagget for mva ved fakturering, og gå gjennom fakturanummereringen. Velg format.
3. Januar til mars 2027: utvikling. Formatgeneratoren; validering mot EN 16931 og de franske reglene før sending; API-klienten mot plattformen; statushåndtering med en tilstandsmaskin for fakturaen; Encaissée-strømmen fra kundereskontroen; aggregatene for e-rapportering.
4. April og mai 2027: test, og gå deretter i drift frivillig. Testmiljøet først, deretter ekte fakturaer til noen kunder som sier ja. Veiledningen tillater frivillig utstedelse før fristen, og feiler det, kan du falle tilbake på den vanlige metoden for de flytene. Våren 2027 er den billigste testingen i drift du kommer til å få.
5. Juni og juli 2027: utvid. All innenlands B2B gjennom plattformen, e-rapporteringen i gang, den første månedsavslutningen og mva-meldingen avstemt mot det plattformen har rapportert.
6. August 2027: frys. Ingen nye versjoner, en skriftlig rutine for avvisninger fra plattform og kjøper, og navngitte personer som dekker feriene.
7. 1. september 2027: plikt. Deretter den første fristen for e-rapportering, den egentlige testen av rapporteringssiden.

Hvis du ikke er klar på dagen

Veiledningen som ble skrevet for oppstarten i september 2026, legger en tolerant linje: ingen sanksjoner i oppstartsfasen for selskaper som møter vansker, men er på en «trajectoire sérieuse de mise en conformité», vurdert ut fra konkret, datert dokumentasjon (plattformkontrakt, tester, supportsaker). Den sier også at dette er «ni un report ni une suspension» av plikten, altså verken en utsettelse eller en suspensjon. Den sier ikke om den samme linjen vil gjelde i september 2027.

Sanksjonene står i spørsmålene og svarene: 50 euro per faktura som ikke er utstedt elektronisk, begrenset oppad til 15 000 euro per kalenderår, og det første bruddet sanksjoneres ikke. Mangler ved e-rapporteringen faller inn under artikkel 1788 D i CGI.

Behandle 1. september 2027 som fast, og ta vare på dokumentasjonssporet uansett: det er det myndighetene kommer til å be om.

Hvor dette passer inn

De fleste franske PME vil få dette fra programvareleverandøren, og bør gjøre det. Vårt arbeid er for de andre: vi bygger formatgenereringen, plattformkoblingen, statushåndteringen og strømmene for e-rapportering inne i systemet som allerede lager fakturaene deres, og vi retter dataene under. Du finner mer om vår tjeneste for e-fakturaintegrasjon, og om ERP-modernisering når selve faktureringssystemet er problemet.

Har du fristen i september 2027 og et faktureringssystem ingen vil røre, skriv til office@c9group.dev. Vi er ingeniører, ikke skatterådgivere: virkeområde og mva-behandling hører hjemme hos deres expert-comptable, og vi bygger etter svaret de gir.