Hva er en EDI-faktura (INVOIC)?
En EDI-faktura er en fakturamelding som sendes maskinlesbart mellom handelspartneres systemer, i stedet for som papir, PDF eller e-postvedlegg. I UN/EDIFACT-standarden heter meldingstypen INVOIC, og den definerer hvilke segmenter og dataelementer fakturaen skal bestå av. Mottakeren kan dermed validere og bokføre fakturaen automatisk, uten manuell registrering.
Nøkkelpunkter:
- INVOIC er meldingstypen for faktura i UN/EDIFACT, forvaltet av UN/CEFACT.
- Meldingen er bygget av segmenter: UNH, BGM, DTM, NAD, RFF, LIN, QTY, PRI, TAX og MOA.
- Fakturaen må referere til tidligere meldinger i kjeden, normalt ORDERS og DESADV.
- Alle beløp må være matematisk konsistente: linjesummer, avgifter og totaler skal stemme.
- Treveis-kontroll mot ordre og leveranse er hovedgrunnen til at kjedene krever EDI-faktura.
- EDI-faktura og EHF er ikke det samme, men løser overlappende behov.
Hvordan fungerer en EDI-faktura (INVOIC)?
Interne fakturadata konverteres til INVOIC-format og sendes elektronisk til kjøperens system. Prosessen har seks trinn:
- Fakturaen opprettes i leverandørens ERP- eller regnskapssystem, basert på leverte varer eller tjenester.
- Dataene eksporteres til EDI-laget, altså en konverter eller middleware.
- Konverteren mapper interne felter til INVOIC-segmenter. Se EDI-mapping for hvordan dette settes opp.
- Meldingen sendes via en sikker kanal, normalt AS2, SFTP eller VAN.
- Kjøperens system validerer meldingen mot syntaks, struktur og forretningsregler.
- Godkjent faktura bokføres automatisk i kjøperens økonomisystem.
Trinn 3 er der oppsettarbeidet ligger, og trinn 5 er der det meste går galt.
Hvilke segmenter består meldingen av?
En INVOIC-melding er bygget av segmenter med faste treboks-koder, i en definert rekkefølge. Hvert segment bærer én type informasjon:
| Segment | Innhold |
|---|---|
| UNH | Meldingshode med meldingstype og versjon |
| BGM | Dokumenttype og fakturanummer |
| DTM | Datoer: fakturadato, forfallsdato, leveringsdato |
| NAD | Partsidentifikasjon, normalt med GLN |
| RFF | Referanser til ordre, leveranse og kontrakt |
| LIN | Varelinje, normalt med GTIN |
| QTY | Fakturert antall |
| PRI | Enhetspris |
| TAX | Avgiftskategori og sats |
| MOA | Beløp: linjesum, avgiftsbeløp, totalsum |
RFF er segmentet som binder fakturaen til resten av transaksjonskjeden, og MOA er det som må stemme matematisk. De to står bak de fleste avvisningene.
Hvilke segmenter som er obligatoriske, og hvilke koder som er gyldige, defineres av handelspartnerens gjeldende implementeringsguide, ikke av standarden alene. Se EDIFACT for hvordan standarden er bygget opp.
Hvilke data inneholder en EDI-faktura (INVOIC)?
Hodenivå
Hodedata gjelder for hele dokumentet og identifiserer transaksjonen:
- Fakturanummer og fakturadato
- Leverandør- og kjøperidentifikasjon, normalt GLN
- Organisasjonsnummer og MVA-nummer
- Valuta og betalingsbetingelser
- Referanse til innkjøpsordre
- Referanse til leveranse
Hodedataene brukes til å bekrefte at fakturaen tilhører riktig handelspartner og at de økonomiske referansene finnes hos mottakeren.
Linjenivå
Hver fakturalinje beskriver ett produkt eller én tjeneste:
- Produktidentifikator, normalt GTIN, alternativt SKU eller internt varenummer
- Fakturert antall
- Enhetspris
- Linjebeløp
- Avgiftskategori og avgiftssats
- Referanse til levering eller forsendelse
Linjene må normalt samsvare med tidligere godkjent innkjøpsordre, bekreftet leveranse og registrert varemottak. Det er denne sammenligningen som gjør automatisert fakturabehandling mulig.
Sammendrag og totaler
Meldingen avsluttes med økonomiske oppsummeringer: linjetotaler, avgiftstotaler, rabatter eller tillegg, MVA-spesifikasjon per sats, og totalt fakturabeløp.
Alle beløp må være matematisk konsistente. Summen av linjene skal stemme med fakturatotalen, avgiftene skal være korrekt beregnet, og delsummer skal henge sammen med totalen. Et avrundingsavvik på én krone er nok til at meldingen avvises.
Hvilke systemer kreves for å sende en EDI-faktura?
Tre komponenter må være på plass:
| Komponent | Rolle |
|---|---|
| ERP- eller regnskapssystem | Genererer fakturadata: kunde- og produktdata, avgiftssatser, leverings- og betalingsbetingelser |
| EDI-konverter | Mapper interne felter til INVOIC-segmenter, anvender kodelister og genererer korrekt meldingsstruktur |
| Kommunikasjonskanal | Overfører meldingen kryptert, med leveringsbekreftelse og sporbarhet |
Kanalen er normalt AS2, SFTP, et VAN-nettverk eller en API-basert gateway. Oppsettet må støtte datasikkerhet i EDI-transaksjoner og være i samsvar med kjøperens tekniske spesifikasjon.
Hvordan valideres en EDI-faktura (INVOIC)?
Valideringen skjer i fem lag, fra det tekniske til det økonomiske:
| Lag | Hva som kontrolleres | Typisk feil |
|---|---|---|
| Syntaks | Meldingshode, segmentstruktur, skilletegn, tegnsett | Ugyldig struktur, ødelagte norske tegn |
| Struktur | Obligatoriske segmenter, rekkefølge, tillatte gjentagelser | LIN uten tilhørende QTY |
| Dataelementer | Format og gyldige verdier for fakturanummer, avgifts- og valutakoder, partidentifikatorer | MVA-kode utenfor kodelisten |
| Referanseintegritet | At ordren finnes, at leveringsreferansen samsvarer med DESADV, at fakturert antall ikke overstiger levert | Faktura mot en ordre mottakeren ikke kjenner |
| Økonomisk konsistens | Linjesummer mot total, avgiftsberegning, delsummer | Avrundingsavvik i totalen |
Feiler ett lag, stoppes meldingen der, og feilmeldingen sier ingenting om lagene under. Avviste fakturaer bokføres ikke. Se EDI-validering for hvordan kontrollene fungerer generelt.
Hvorfor er EDI-faktura (INVOIC) nødvendig i detaljhandelsintegrasjon?
En EDI-faktura er nødvendig for å støtte automatisert økonomisk avstemming i EDI-baserte detaljhandelsmiljøer.
Retail-systemer opererer ofte med:
- automatisert varemottak
- høye transaksjonsvolumer
- integrerte lagersystemer
- automatisert treveis-kontroll
Treveis-kontroll innebærer at systemet sammenligner tre dokumenter:
- Innkjøpsordre
- Leveringsinformasjon
- Faktura
Manuelle fakturaformater som PDF eller papir kan ikke behandles automatisk i slike prosesser.
INVOIC-meldingen gjør det mulig å:
- bokføre fakturaer automatisk
- gjennomføre treveis-kontroll
- generere korrekt MVA-rapportering
- sikre elektronisk sporbarhet
- fremskynde betalingsgodkjenning
I en standard EDI-kjede for detaljhandel sendes fakturaen etter at flere tidligere meldinger er behandlet.
Typisk meldingsrekkefølge er:
- ORDERS – innkjøpsordre
- ORDRSP – ordrebekreftelse
- INVOIC – faktura
INVOIC-meldingen fullfører den kommersielle transaksjonen og utløser den økonomiske oppgjørsprosessen mellom handelspartnerne.
EDI-faktura, EHF eller PDF?
Tre former for faktura brukes om hverandre i norsk B2B, og de løser ulike behov:
| Format | Hva det er | Brukes mot |
|---|---|---|
| INVOIC | EDIFACT-meldingstypen for faktura | Dagligvare- og varehandelskjeder |
| EHF | Norsk fakturaformat basert på Peppol BIS, sendt over Peppol | Offentlig sektor, og stadig flere private |
| Visuelt dokument, ikke maskinlesbart | Mindre kunder uten integrasjon |
En virksomhet kan sende EHF-faktura uten å ha EDI på ordre- og leveransemeldingene. Motsatt krever noen innkjøpere sitt eget XML-format i stedet for begge, som Vinmonopolet. Hvilket format som gjelder, bestemmes alltid av mottakeren.
Viktige konklusjoner
- En EDI-faktura er en maskinlesbar fakturamelding som behandles automatisk hos mottakeren.
- I UN/EDIFACT heter meldingstypen INVOIC, og den er bygget av definerte segmenter.
- Hodedata identifiserer transaksjonen, linjedata beskriver varene, og totalene må stemme matematisk.
- Fakturaen må referere til tidligere meldinger i kjeden for å kunne kontrolleres.
- Validering skjer i fem lag; feil i ett lag skjuler feilene i lagene under.
- Treveis-kontroll mellom ordre, leveranse og faktura er hovedgevinsten.
- EHF og INVOIC er ikke det samme, og noen innkjøpere krever sitt eget XML-format.
- INVOIC-meldingen muliggjør automatisert økonomisk avstemming, treveis-kontroll og mer effektiv betalingsbehandling mellom handelspartnere.
Spørsmål og svar
Ofte stilte spørsmål
Her svarer vi på de vanligste spørsmålene vi får fra nye og eksisterende kunder.
En EDI-faktura er en fakturamelding som sendes strukturert mellom handelspartneres systemer i stedet for som papir eller PDF. I UN/EDIFACT-rammeverket heter meldingstypen INVOIC. Fakturadata overføres direkte fra leverandørens ERP-system til kjøperens økonomisystem, hvor de kan valideres og bokføres automatisk. Forskjellen fra en PDF er at innholdet er maskinlesbart felt for felt, ikke bare et bilde av en faktura.
INVOIC er navnet på meldingstypen for faktura i UN/EDIFACT-standarden. Den definerer hvilke segmenter fakturaen skal bestå av og i hvilken rekkefølge: UNH for meldingshode, BGM for dokumenttype og fakturanummer, NAD for partsidentifikasjon, RFF for referanser, LIN for varelinjer, og MOA for beløp. Hvilke av dem som er obligatoriske, bestemmes av handelspartnerens implementeringsguide.
En PDF er et visuelt dokument. Innholdet må leses av et menneske eller tolkes med tekstgjenkjenning før det kan registreres. En EDI-faktura er strukturert: hvert felt har et definert navn, format og plassering, slik at mottakerens system kan lese det direkte. Det er denne forskjellen som gjør automatisk bokføring og treveis-kontroll mulig, og som er grunnen til at større kjeder ikke aksepterer PDF.
EHF er et norsk fakturaformat basert på Peppol BIS, som sendes over Peppol-nettverket og er obligatorisk mot offentlig sektor. INVOIC er EDIFACT-meldingstypen for faktura, brukt i varehandelen. Begge er maskinlesbare, men de bruker ulik struktur og ulike kanaler. En leverandør kan sende EHF til det offentlige og INVOIC til dagligvarekjedene, fra samme ERP-data, men med to separate oppsett.
Fordi fakturavalideringen kontrollerer sammenhengen mellom bestilt, bekreftet, levert og fakturert mengde. Ordren kan passere sin egen validering, mens avviket først blir synlig når fakturaen sammenlignes med pakkseddelen. Vanlige årsaker er delleveranser som ikke er reflektert i faktureringen, prisavvik mot avtalte betingelser, manglende referanse til DESADV, eller et avrundingsavvik mellom linjesummer og total.
Ja. ERP-systemet trenger ikke innebygd EDI-funksjonalitet, men må kunne eksportere fakturadata strukturert eller tilby API-tilgang. En konverter eller integrasjonsplattform håndterer mapping til INVOIC-segmenter, validering og kommunikasjon utenfor ERP-systemet. Har ERP-leverandøren en EDI-modul, kan den være raskere å ta i bruk, men den er begrenset til formatene leverandøren støtter.
Neste anbefalt artikkel
Kort oppsummering som binder leseren videre til et dykkemal - typisk neste steg i brukerens reise.
Tilbake til Aktuelt
Hva er PRICAT? Priskatalog i EDI
PRICAT er meldingstypen som brukes til å sende produkt- og prisinformasjon fra en leverandør til en…