En dataspesifikasjon for elektronisk bilag beskriver hvilke felter et bilag skal inneholde, hvordan de skal struktureres, og hvordan systemer kan validere dem. Spesifikasjonen er ryggraden i alt fra fakturaer og kvitteringer til reisedokumenter og kreditnotaer. Når den er tydelig, blir bilagsbehandling raskere og kontrollen mer pålitelig.

Hva en god spesifikasjon dekker

ElementHva det betyr
FelterHvilke datapunkter som skal være med
DatatyperHvordan hvert felt skal kodes (tekst, dato, beløp)
Obligatoriske vs valgfrieHva som må stå, og hva som kan utelates
ValideringRegler som filen må oppfylle
EksemplerKonkrete bilag som viser riktig bruk
VersjoneringHvordan endringer beskrives og vedlikeholdes

Hvorfor felter alene ikke er nok

Mange spesifikasjoner lister felter, men gir ikke nok hjelp til å bruke dem riktig. Resultatet blir at hvert system implementerer egne tolkninger.

  • felt for «referanse» kan brukes til ordrenummer, prosjektkode eller leverandørreferanse
  • felt for «leveringsdato» kan tolkes som faktisk eller forventet
  • felt for «MVA-kode» kan ha lokale koder uten kobling til standard

Bedre Standard mener at gode spesifikasjoner må gi definisjoner og avgrensninger, ikke bare felter.

Validering som integrert del

En spesifikasjon uten validering er en ønskeliste. Validering bør finnes på flere nivåer:

  1. syntaks — er filen i riktig format?
  2. datatype — er feltene av riktig type?
  3. forretningsregler — er beløpene konsistente, sum lik delsum?
  4. referanseintegritet — finnes refererte kunder, kontoer, prosjekter?

For e-faktura finnes etablerte valideringer som Peppol BIS Billing 3.0, og disse er gode forbilder også for andre bilagstyper.

Sammenheng med eksisterende standarder

Et elektronisk bilag står sjelden alene. Det forholder seg til:

En god spesifikasjon må vise hvordan den passer inn i dette landskapet — ikke pretendere å være isolert.

Versjonering uten brudd

Et bilag som er gyldig i dag, må ofte være lesbart i 5–10 år. Det stiller krav til hvordan formatet kan utvikles uten å bryte eksisterende implementasjoner.

  • bakoverkompatible utvidelser
  • klare overgangsfaser
  • tydelig dokumentasjon av hva som er deprecated
  • testdata for hver versjon

Se versjonering av standarder for prinsippene.

Hva spesifikasjonen ofte bør gi mer av

  • Eksempler på vanskelige tilfeller: korreksjoner, valuta, deltakere
  • Forklaring av hvorfor felter finnes — ikke bare hva de heter
  • Avvisningsregler og hvordan systemet skal kommunisere feil
  • Migrasjonshjelp ved overgang mellom versjoner

Videre lesing

Bedre Standard inviterer leverandører og fagmiljøer til å bidra. Se våre prioriterte standarder og samarbeidsmuligheter .