Hela orderns väg på en tidslinje, ända till betald nätfaktura.
En order i en finländsk partihandel eller verkstad rör sig genom affärssystem, CRM, nätbutik, lager, speditör och ekonomi innan betalningen syns på kontot. Vi binder ihop systemen med dokumenterade API:er och händelser, så att varje order har en enda status överallt. Går något snett tar en AI-agent fram ett förslag, och en människa säger ja eller nej innan något verkställs.
För finländska företag och offentliga köpare som säljer, köper och fakturerar med nätfakturor, ofta också via systerbolag i Sverige och Baltikum.
Kundordern, inköpsordern eller serviceuppdraget skapas bara i det system som är ägare, och resten av systemen får uppgiften via API:er och händelser. Av statushändelserna byggs en tidslinje för varje order. Om ett moment fallerar eller går över toleransen samlar en AI-agent ihop fakta och lägger fram ett förslag; en människa godkänner det innan ägarsystemet verkställer. Fakturorna går som nätfakturor och matchas automatiskt, och processägarna håller koll på flödet och gränssnittens hälsa.
Före och efter
Så förändras vardagen
I dag
Med systemet
I dag
I dag: Samma order skrivs in om och om igen
Det som säljaren eller nätbutiken tagit emot knappas in en gång till i affärssystemet, och lagret, speditören och bokföringen får sina uppgifter genom kopiering.
Med systemet
Med systemet: En inmatning räcker
Order, leveranser och fakturor föds i sitt ägarsystem och skickas ut som händelser. Övriga system lyssnar på händelserna och behöver inte skriva in något på nytt.
I dag
I dag: Statusen är från i går
Gränssnitten går en gång per natt, så kundtjänst, planering och ekonomi har var sin gammal bild av ordern. Kunden som undrar var paketet är får vänta på att någon ringer tillbaka.
Med systemet
Med systemet: En status som alla ser
Varje order eller uppdrag får en tidslinje av händelserna i alla system den passerar. Kundtjänst, planering och ekonomi ser samma sak, och det gör också assistenten för kund- och medborgarservice när kunden frågar hur det går.
I dag
I dag: Problem som löses i e-posten
Restorder, fel pris, leveranser som inte gått fram och nätfakturor som mottagaren returnerat reds ut i e-post och kalkylblad. I efterhand vet ingen vem som bestämde vad.
Med systemet
Med systemet: Ett förslag följer med problemet
AI-agenten plockar fram uppgifterna kring avvikelsen och föreslår en lösning. Medarbetaren godkänner, justerar eller förkastar förslaget i avvikelsekön, och beslutet sparas.
I dag
I dag: Grunddata som säger olika
En och samma kund, leverantör, artikel eller prislista har olika värden i olika system, och ingen har ansvaret för vilket som är rätt.
Med systemet
Med systemet: Varje dataobjekt har en ägare
Kunder, leverantörer, artiklar och priser har ett bestämt ägarsystem och en namngiven ansvarig. Dubbletter och motsägelser meddelas den ansvariga i stället för att lappas ihop i tysthet längre fram.
I dag
I dag: Varje nyhet kräver ett nytt gränssnitt
En ny kanal, marknadsplats eller ett nytt dotterbolag betyder ännu en direktkoppling. Nätfakturorna i Finland och andra länders e-fakturakrav lägger dessutom till egna format och nätverk.
Med systemet
Med systemet: Nya kopplingar på samma kontrakt
En ny kanal, ett nytt bolag eller ett nytt fakturanätverk ansluts till de dokumenterade API:erna och händelserna en enda gång, inte till varje system separat.
Arbetsflöde
Arbetsflödet steg för steg
Med rena uppgifter går huvudvägen utan handpåläggning. Avviker en order, leverans eller nätfaktura tar slingan ärendet till en människa med fakta och förslag, och rättelsen går tillbaka genom samma integrationslager.
Exempel på arbetsflöde
7 steg · 1 mänsklig kontrollpunkt
Teckenförklaring
System
AI-agent
Människa
Mänsklig kontrollpunkt
Undantagsflöde
Sammankopplade processer: illustrativt arbetsflöde med slinga för avvikelser
Läs diagrammet som text
Huvudvägen börjar med att en affärshändelse skapas en gång i ägarsystemet, fortsätter med spridning via API:er och händelser och en tidslinje för varje order, och går vidare till fakturering, matchning och betalning. Sist går processägarna igenom flödet och rättar orsakerna till avvikelserna.
Fallerar ett moment, blir det sent eller går utanför toleransen, viker avvikelsen av från huvudvägen efter tidslinjen. AI-agenten samlar fakta och föreslår en lösning som en människa godkänner, justerar eller förkastar. Det godkända verkställs i ägarsystemet och kommer tillbaka till spridningssteget som en ny händelse.
Godkännandet är den mänskliga kontrollpunkten: ingen bokföring, ingen ändring av pris eller kreditgräns och inget löfte till kunden sker utan en människa.
01
Steg 1: Skapa uppgiften en gångSystem
Kundordern kommer från nätbutiken, en marknadsplats, EDI eller säljarna; inköpsorder och serviceuppdrag skapas på samma sätt i sitt ägarsystem. Systemet sänder en affärshändelse i ett CloudEvents-kuvert enligt ett AsyncAPI-kontrakt. Order och leverantörsfakturor på papper eller som PDF passerar först dokumenttolkning.
02
Steg 2: Dela via API:er och händelserSystem
Integrationslagret för händelsen vidare till lagret, transporten, ekonomin och CRM genom deras dokumenterade API:er (OpenAPI). Mottagarna tål att samma meddelande kommer två gånger utan att en extra försändelse eller faktura uppstår, och det som inte går fram parkeras i en felkö för ny körning.
03
Steg 3: Tidslinje för varje orderSystem
Statusar från alla system, som bekräftad, plockad, avsänd, levererad, fakturerad och betald, knyts ihop med affärsreferensen till en tidslinje. Regler för milstolpar och toleranser larmar när något fallerar, blir sent eller inte går ihop: en restorder, ett pris utanför avtalet, en leverans som inte gått fram eller en returnerad nätfaktura.
04
Steg 4: Samla fakta och föreslåAI-agent
AI-agenten hämtar det den behöver ur de berörda systemen: ordern, saldot i lagret, prisavtalet, speditörens status och kundens villkor. Sedan lägger den fram ett förslag med motivering och källuppgifter, till exempel en ersättningsartikel, ett justerat pris, en ny leveransdag eller en rättad faktura.
Undantagsflöde: Moment fallerat eller över toleransen
05
Steg 5: Godkänn inom ramarnaMänniska
En medarbetare på kundtjänsten, i logistiken eller på ekonomiavdelningen ser problemet, underlaget och förslaget i avvikelsekön och godkänner, justerar eller förkastar det. Ägarsystemets API verkställer det godkända, och ändringen sänds ut som en ny händelse.
Undantagsflöde: Moment fallerat eller över toleransen· Återgår till steg 2
Mänsklig kontrollpunkt
Utan godkännande bokför agenten ingenting, rör inga priser eller kreditgränser och lovar inget åt kunden. Beloppsgränser per typ av åtgärd styr vem som godkänner, och varje förslag och beslut loggas.
06
Steg 6: Fakturera och stäm avSystem
Utgående fakturor går från affärssystemet som nätfakturor enligt Europanormen (EN 16931, Peppol BIS Billing 3.0) genom en accesspunkt. Inkommande leverantörsfakturor paras ihop med inköpsorder och varumottagning, och när banken eller betaltjänsten meddelar betalning stängs tidslinjen.
07
Steg 7: Rätta orsakernaMänniska
Med jämna mellanrum går processägarna och integrationsteamet igenom avvikelserna sorterade på orsak, liksom fel i gränssnitten och motsägelser i grunddata. De rättar felet vid källan, i en grunddatapost, en toleransregel eller en mappning, så att samma problem inte kommer tillbaka.
Komponenter
Vad vi bygger
01
Händelsestyrt integrationslager
Kontraktsstyrda API:er och händelser mellan affärssystem, CRM, nätbutik, lager, transport och ekonomi, beskrivna i OpenAPI och AsyncAPI med CloudEvents-kuvert, ovanpå din nuvarande integrationsplattform eller byggda direkt i molnet.
Bestämt ägarsystem och ansvarig för varje dataobjekt, regler som parar ihop kunder, leverantörer och artiklar, och rapporter om dubbletter och motsägelser till dem som äger uppgifterna.
En tjänst som knyter ihop händelserna till en tidslinje för varje order eller uppdrag, tillämpar regler för milstolpar och toleranser och visar processägarna hur flödet går och var det stockar sig.
En kö där varje avvikelse visas med insamlade fakta och agentens förslag, knappar för att godkänna, justera och förkasta, och beloppsgränser per åtgärdstyp som kontrolleras just där åtgärden verkställs.
Fakturor i UBL enligt Europanormen (EN 16931, Peppol BIS Billing 3.0) som går ut och kommer in genom en accesspunkt och valideras innan de skickas. Returnerade fakturor landar i avvikelsekön.
Hälsoövervakning och larm för varje gränssnitt, instruktioner för driften och styrd omkörning av meddelanden som fastnat, uppsatt som infrastruktur som kod i din molnmiljö.
SAP S/4HANA för försäljning, inköp och ekonomiPlattformSAP
Salesforce Sales, Service och Commerce CloudPlattformSalesforce
Odoo för försäljning, lager, inköp och bokföringPlattformOdoo
E-handelsplattformar, marknadsplatser och speditörernas API:er
Lagerstyrning och transportplanering
Peppol-accesspunkt, banker och betaltjänster
Produktdata och dataplattformen
Kontroller
Kontroller från början
Åtkomstgränser
Integrationerna och agenten har var sin tjänsteidentitet i varje system och når bara de API-anrop som behövs. Agenten får läsa i flera system för att samla fakta, men den kan skriva bara genom ett fåtal godkända åtgärder, som ägarsystemets API verkställer. Direkt åtkomst till databaserna har den inte.
Mänsklig granskning
Tillsammans med processägaren bestämmer vi för varje åtgärdstyp vad agenten bara får föreslå, vad en medarbetare kan godkänna och vad som kräver två personer. Bokföring, pris- och kreditgränsändringar och löften till kunder väntar alltid på en människa. Små åtgärder som går att ångra, som att köra om ett meddelande som fastnat, kan gå automatiskt om ägaren vill det.
Spårbarhet
Händelser, förslag, godkännanden, avslag och verkställda åtgärder loggas mot orderns eller uppdragets referens, med de uppgifter agenten använde, modell- och promptversion och namnet på den som godkände. En omtvistad faktura eller en reklamation går att följa steg för steg.
Dataskydd
Kontaktuppgifter till kunder och leverantörer skickas bara dit de behövs. Tidslinjen innehåller referenser och statusar, inte hela poster, och loggarna gallras enligt de tider du bestämmer. Uppgifterna behandlas i den region som avtalats.
Transparens kring AI
I avvikelsekön är agentens förslag tydligt märkta, med fakta och motivering bredvid. Ägarsystemen har sista ordet: tidslinjen visar vad de rapporterar men skriver aldrig över dem.
Mått
Vad vi följer upp
Vi väljer måtten med dig under förstudien och tar nollnivån ur dagens system- och gränssnittsloggar innan något ändras.
Vad vi följer upp
Mått
Varför det är viktigt
Så skulle vi mäta det
01Orderns genomloppstid
Varför det är viktigtKunden märker den först, och den visar var orderna blir liggande.
Så skulle vi mäta detTiden från order till leverans och vidare till betalning, per kanal och bolag, ur händelserna på tidslinjen.
02Order utan handpåläggning
Varför det är viktigtVisar hur mycket av flödet som klarar sig på rena uppgifter och överenskomna regler.
Så skulle vi mäta detHur stor del av order och uppdrag som når betalning helt utan manuella moment eller avvikelser, enligt tidslinjen.
03Avvikelser per orsak och tid till lösning
Varför det är viktigtPekar ut vilka orsaker som ska åtgärdas först och om kön hinner betas av.
Så skulle vi mäta detAvvikelser per orsakskod och tiden från larm till verkställd lösning, ur avvikelseköns loggar.
04Returnerade nätfakturor
Varför det är viktigtEn returnerad faktura skjuter upp betalningen och beror oftast på fel i grunddata eller mappning.
Så skulle vi mäta detAndelen skickade och mottagna nätfakturor som returnerats, efter orsak, ur svaren från accesspunkten.
05Fel i gränssnitten och tid till åtgärd
Varför det är viktigtVisar om integrationslagret går att lita på och om fel märks och rättas fort.
Så skulle vi mäta detMeddelanden som fastnat per gränssnitt och tiden tills de körts om med lyckat resultat, ur övervakningen.
06Dubbletter och motsägelser i grunddata
Varför det är viktigtBakom de flesta avvikelser ligger uppgifter som skiljer sig mellan systemen.
Så skulle vi mäta detÖppna dubbletter och motstridiga värden per dataobjekt och system, ur rapporterna från matchningen.
Vi sätter inga mål förrän utgångsläget har mätts.
Införande
Införandet i faser
Fas 01
Förstudie och processkarta
En process, till exempel order till betalning i en enda kanal, och en sorts avvikelse. Vi ritar upp systemen, gränssnitten, dataägarna och hur problemen löses i dag.
Kriterier för att gå vidare
Process, system och dataägare kartlagda
Första avvikelsen och beloppsgränserna bestämda
Nollnivån uppmätt ur dagens loggar
Fas 02
Integration och tidslinje
Dokumenterade API:er och händelser för de system som ingår, och tidslinjen igång bredvid de gamla gränssnitten utan att de rörs.
Kriterier för att gå vidare
Händelsekontrakten publicerade med versioner
Tidslinjen stämmer med ägarsystemen för ett urval order
Omkörning och driftinstruktioner provade
Fas 03
Avvikelsekön i pilot
Agenten föreslår lösningar för den valda avvikelsen, och varje förslag godkänns av en människa. Vi jämför förslagen med det personalen själv hade gjort.
Kriterier för att gå vidare
Förslagen håller den kvalitet som bestämts
Beloppsgränser och godkännare per åtgärdstyp fastställda
Ekonomi och intern kontroll har gått igenom loggspåret
Fas 04
Bredda och stäng av
Fler avvikelser, kanaler, bolag och processer, som inköp till betalning, alla på samma kontrakt. De gamla direktkopplingarna stängs en efter en.
Kundorder och reservdelsorder hos tillverkare av elektronik, instrument eller möbler, från affärssystemet till lagret och speditörerna, med leverantörsbekräftelser och nätfakturor matchade mot inköpsorder.
Arbetsorder, underentreprenörernas inköpsorder och deras fakturor hos entreprenörer för väg- och gatuunderhåll, följda från beställning till betalning.
Inköp till betalning i ett välfärdsområde eller en kommun, där nätfakturor enligt Europanormen paras ihop med beställning och mottagning innan något betalas.
Illustrativt exempel
En partihandel i Finland, Sverige och Estland
Utgångsläge
En partihandel med tekniska förnödenheter säljer via nätbutik, en marknadsplats och egna säljare i Finland, Sverige och Estland från två lager. Orderna knappas in på nytt i affärssystemet, speditörerna meddelar leveransproblem per e-post, och kommuner och välfärdsområden som kunder kräver nätfakturor enligt Europanormen.
System
Order, lagersaldon, försändelser och fakturor går som händelser mellan nätbutiken, affärssystemet, lagret och speditörerna, och varje order har sin tidslinje. Fakturorna går ut som nätfakturor genom en accesspunkt, i det nätverk och format som varje land och kund kräver.
Mänsklig kontroll
Restorder och leveranser som inte gått fram hamnar i samma avvikelsekö, där AI-agenten föreslår en ersättningsartikel eller en ny leveransdag. Kundtjänsten godkänner varje förslag, och prisändringar och kreditnotor kräver ett ja från ekonomiavdelningen.
Det här skulle vi mäta
Andelen order utan handpåläggning per land och kanal, avvikelser per orsak och tid till lösning, och andelen returnerade nätfakturor per land.
Finland
Nätfakturor i Finland, andra regler i grannländerna
Många finländska företag har dotterbolag i Sverige och Baltikum och kör order till betalning och inköp till betalning på olika installationer av affärssystemet, med olika speditörer och banker. I Finland är nätfakturan redan norm: lagen om elektronisk fakturering (241/2019) ger företag och upphandlande enheter rätt att på begäran få sina fakturor som nätfakturor, och Statskontoret är Finlands Peppol-myndighet. I andra länder kommer kraven vid olika tidpunkter, och ViDA gör strukturerad e-fakturering till huvudregel för B2B-leveranser mellan EU-länder från 1 juli 2030. Vi lägger varje lands format och nätverk bakom samma händelser, så att ett nytt krav blir en ny koppling och inte en ny process.
Dataförordningen, som tillämpas sedan 12 september 2025, reglerar byte mellan databehandlingstjänster, så händelsekontrakt och dataexport hålls portabla. Agenterna i avvikelsekön utformas med AI-förordningen i åtanke, och integrationerna har loggad åtkomst och dokumenterade komponenter för kunder som omfattas av cybersäkerhetslagen (124/2025) och ska kunna visa att leveranskedjan är säker.
Nej. Affärssystemet, CRM, nätbutiken och lagret gör var sitt jobb. Vi integrerar runt dem, bestämmer vilket system som äger vilka uppgifter och lägger en tidslinje över helheten. Om ett gammalt order- eller affärssystem stoppar all förändring börjar vi med att ställa API:er framför det, så som modernisering av äldre system beskriver.
02Ska vår integrationsplattform bytas?
Inte om den sköter sig. Vi bygger vidare på den integrationsplattform eller meddelandekö som redan finns och kompletterar med kontrakt, övervakning och omkörning där det behövs. Saknas en sådan bygger vi direkt i molnet. Läs mer om integrationer och API:er.
03Får AI-agenterna göra saker själva?
Bara inom beloppsgränser som bestämts per åtgärdstyp, och bara när åtgärden är liten och går att ångra, till exempel att köra om ett meddelande som fastnat. Bokföring, priser, kreditgränser och löften till kunder kräver alltid en människa. Läs om när AI-agenter behöver mänskligt godkännande.
04Var kommer nätfakturorna in i bilden?
I Finland är nätfakturan vardag. Lagen om elektronisk fakturering (241/2019) kräver att upphandlande enheter tar emot och behandlar nätfakturor, och sedan 1 april 2020 har företag och upphandlande enheter rätt att på begäran få sina fakturor från varandra som nätfakturor. Staten tar endast emot nätfakturor, och en PDF-faktura per e-post räknas inte som nätfaktura. Andra länder inför sina krav i olika takt, och EU:s paket om mervärdesskatt i den digitala tidsåldern (ViDA) gör strukturerad e-fakturering till huvudregel för B2B-leveranser mellan EU-länder från 1 juli 2030. För oss är fakturan en händelse bland andra: den skapas i affärssystemet, går ut genom en accesspunkt och hamnar i avvikelsekön om mottagaren returnerar den. Läs mer om nätfaktura och Peppol i Finland.
05Hur slipper vi ännu ett virrvarr av direktkopplingar?
Systemen talar med varandra genom ett gemensamt lager av dokumenterade händelser och API:er, aldrig direkt. Kontrakten har versioner, mottagarna klarar dubbla meddelanden, det som fastnat kan köras om och varje flöde har en namngiven ägare. En ny kanal kopplar in sig på befintliga händelser och behöver ingen egen tråd till varje system.
06Vad tar man först?
En process och en sorts avvikelse, till exempel order till betalning i en kanal där restorder är det första problemet. Då ser man att händelserna, tidslinjen och godkännandet fungerar innan något mer läggs till. Läs om vårt arbetssätt.
Visa oss dina order- och fakturaflöden
Välj en process och de länder och bolag där den körs. Tillsammans med dig ritar vi upp system, gränssnitt och avvikelser och föreslår en första version som fungerar i alla bolagen.