För många europeiska programvaruleverantörer börjar e-fakturering som ett enkelt produktbeslut. Ett regelverk är på gång, eller så finns det en tydlig efterfrågan från kunden. Hur svårt kan det vara?
Att lansera e-fakturering kanske inte är så komplicerat, men allt som kommer efter det brukar visa sig vara en.
Det som ofta börjar som ett begränsat utvecklingsprojekt blir snabbt till en långsiktig infrastruktur med regelverksmässiga, operativa och kommersiella konsekvenser som är lätta att underskatta.
Vi tar reda på varifrån den verkliga kostnaden för att bygga en egen e-fakturalösning i Europa kommer och varför den tenderar att växa över tid.
De flesta team planerar för den första releasen: scheman, valideringar, anslutningar, tester. Arbetet är synligt, avgränsat och passar bra in i en färdplan.
E-fakturering i Europa utvecklas ständigt och det innebär att e-fakturering inte är en ”bygg en gång och gå vidare”-funktion. Det finns ViDA, nationella regelverk, Peppol och så många lokala tolkningar av allt detta som du kan räkna. Och de rör sig alla på olika tidslinjer.
I praktiken innebär detta ett löpande arbete. När ni går live måste ni kontinuerligt anpassa er till nya regler, marknader och växande volymer (om ni har tur). Teamets att göra-lista utökas snabbt med saker som:
Spårning av regeltidsplaner och ändringar av omfattning
Uppdatering av dokumentformat och valideringsregler
Hantering av landsspecifika undantag
Omcertifiering av anslutningar och nätverk
Även inom EU förändras kraven sällan synkront och detta är något ni behöver förbereda er på redan innan lansering.
Fakturering är en affärskritisk del av dina kunders dagliga verksamhet. Det finns mycket lite utrymme för fel. Om något går sönder märker dina kunder det och ni förväntas åtgärda omgående.
När du har e-fakturering i produktionen hanterar du identifieringssökningar, routinglogik, kvitteringar, omförsök och fel i olika nätverk. Varje ytterligare kund och land ökar antalet saker som kan gå fel.
För att inte tala om det operativa arbetet som följer med allt detta: övervakning, incidentrespons, support och revisionsberedskap. Inget av detta är särskilt synligt under den inledande planeringen, men när dina kunder väl börjar använda lösningen i stor skala kan ni inte komma undan. För många leverantörer kan e-fakturering börja kännas som ett separat system som de kör tillsammans med sin faktiska produkt.
De flesta utvecklingsteam klarar av denna arbetsbelastning ett tag, men oftast tar det stopp när tillväxten tar fart. Detta kan ske genom ökade fakturavolymer från kunder, fler användare på plattformen eller expansion över landsgränser.
Låt oss ta internationalisering som exempel.
Det kan vara hanterbart att bygga en lösning för er lokala marknad, men ofta exponerar ett andra eller tredje land komplexiteten hos e-fakturering. Det finns olika regler, olika format, olika förväntningar och det som kanske har fungerat bra tidigare behöver tänkas om.
Det är oftast då programvaruleverantörer omprövar sin ursprungliga strategi.
Generellt sett finns det tre vanliga sätt för programvaruleverantörer att hantera e-fakturering:
Bygga och driva allt själv
Använda en grundläggande gateway för leverans
Bädda in ett partner-API som hanterar efterlevnad, routing och drift
Det finns förstås tekniska skillnader, men huvudfrågan är hur mycket långsiktigt ansvar du vill ha: är e-fakturering något du vill underhålla aktivt eller bara något du vill möjliggöra för dina kunder?
Att bygga e-fakturering i Europa är sällan dyrt från dag ett. Det blir dyrt genom ackumulering: regulatoriska förändringar, driftskostnader och gränsöverskridande expansion. Inte för att teamen missuppfattar den första versionens omfattning, utan för att livscykeln är längre och tyngre än den ser ut.
Att förstå detta tidigt gör det lättare att välja ett tillvägagångssätt som fortfarande fungerar när din produkt, dina kunder och dina marknader växer.