For mange europeiske programvareleverandører starter e-fakturering som et enkelt produktvalg. Det kommer et krav, eller det er et klart kundebehov. Hvor vanskelig kan det være?
Å lansere e-fakturering er kanskje ikke en utfordring, men alt som kommer etterpå viser seg vanligvis å være det.
Det som ofte begynner som et avgrenset utviklingsprosjekt, blir raskt til vedlikehold av langsiktig infrastruktur, med regulatoriske, operative og kommersielle konsekvenser som lett undervurderes.
Vi forklarer hvor de reelle kostnadene ved å bygge en egen e-faktureringsløsning i Europa kommer fra, og hvorfor de har en tendens til å øke over tid.
De fleste team planlegger den første utgivelsen: skjemaer, valideringer, tilkoblinger, testing. Det arbeidet er synlig, avgrenset og passer fint inn i et veikart.
E-fakturering i Europa er i stadig utvikling, og det betyr at det ikke er en funksjon du kan «bygge én gang og så går videre». Det finnes ViDA, nasjonale krav, Peppol og like mange lokale tolkninger av dem som du kan telle. Og de følger alle ulike tidslinjer.
I praksis betyr det kontinuerlig arbeid. Når du er i drift, må du kontinuerlig tilpasse deg nye regler, markeder og økende volumer (hvis du er heldig). Teamets oppgaveliste utvides raskt til å inkludere ting som:
Sporing av regulatoriske tidsfrister og endringer i omfang
Oppdatering av dokumentformater og valideringsregler
håndtering av landspesifikke unntak
Resertifisering av tilkoblinger og nettverk
Selv innenfor EU endres krav sjelden samtidig, og det er noe du må forberede deg på allerede før du lanserer.
Fakturering er en forretningskritisk del av dine kunders daglige virksomhet. Det er svært lite rom for feil. Hvis noe går i stykker, legger kundene dine merke til det, og du forventes å fikse det.
Når du bruker e-fakturering i produksjon, håndterer du oppslag av identifikatorer, rutingslogikk, kvitteringer, nye forsøk og feil på tvers av ulike nettverk. Hver ekstra kunde og hvert ekstra land øker antallet ting som kan gå galt.
For ikke å nevne det operative arbeidet som følger med: overvåking, hendelsesrespons, support og revisjonsberedskap. Ingenting av dette er særlig synlig under den innledende planleggingen, men når kundene dine begynner å bruke det i stor skala, kan du ikke unngå det. For mange leverandører kan e-fakturering begynne å føles som et eget system de kjører ved siden av det egentlige produktet sitt.
De fleste utviklingsteam kan håndtere disse arbeidsoppgavene en stund, men vanligvis kommer vendepunktet med vekst. Dette kan skje gjennom økt fakturavolum fra kunder, flere brukere på plattformen din eller utvidelse på tvers av landegrenser.
La oss ta internasjonalisering som et eksempel.
Det kan være mulig å bygge en løsning for det lokale markedet ditt, men ofte avslører det andre eller tredje landet kompleksiteten ved e-fakturering. Det er ulike regler, ulike formater og ulike forventninger, og det som kanskje fungerte godt før, vil kreve en grundig revurdering.
Det er vanligvis da programvareleverandører revurderer den opprinnelige tilnærmingen sin.
I grove trekk er det tre vanlige måter for programvareleverandører å håndtere e-fakturering på:
bygge og drifte alt selv
bruke en enkel gateway kun til levering
integrere et partner-API som håndterer samsvar, ruting og drift
Det er åpenbart tekniske forskjeller, men hovedspørsmålet er hvor mye langsiktig ansvar du ønsker å bære: er e-fakturering noe du vil vedlikeholde aktivt, eller bare gjøre tilgjengelig for kundene dine?
Å bygge e-fakturering i Europa er sjelden dyrt på dag én. Det blir dyrt gjennom akkumulering: regelverksendringer, driftskostnader og grensekryssende ekspansjon. Ikke fordi teamene feilvurderer den første utgivelsen, men fordi livssyklusen er lenger og tyngre enn den ser ut.
Å forstå det tidlig gjør det enklere å velge en tilnærming som fortsatt fungerer når produktet, kundene og markedene dine vokser.