Varje order på en tidslinje, från mottagning till betald faktura.
Order till betalning, inköp till betalning och serviceärende till faktura löper genom affärssystem, CRM, e-handel, lager, transport och ekonomi. Vi kopplar ihop dem med dokumenterade API:er och händelser, ger varje order en gemensam status i alla system och skickar varje undantag till en agent som tar fram ett förslag som en människa godkänner.
För företag och offentliga aktörer i Sverige som säljer, köper och fakturerar genom flera system, med e-fakturor via Peppol och attest i ekonomisystemet.
En kundorder, en inköpsorder eller ett serviceärende registreras en gång i det system som äger uppgiften och sprids till övriga system via dokumenterade API:er och händelser. Statushändelser bygger en tidslinje per order. När ett steg misslyckas eller hamnar utanför toleransen samlar en agent in underlaget och föreslår en åtgärd, som en människa godkänner innan den genomförs i det ägande systemet. Fakturor utväxlas som e-fakturor och matchas, med attest där det krävs, och processägarna följer upp flödet och gränssnittens hälsa.
Före och efter
Vad som ändras i det dagliga arbetet
I dag
Med systemet
I dag
I dag: Skrivs in igen vid varje överlämning
En order som kommer in via webbutiken eller säljteamet skrivs in på nytt i affärssystemet, och leverans- och fakturauppgifter kopieras för hand till lager-, transport- och ekonomisystemen.
Med systemet
Med systemet: Registreras en gång, används överallt
Varje order, leverans och faktura skapas i det system som äger den och publiceras som en händelse. Övriga system prenumererar på händelsen i stället för att skriva in uppgifterna igen.
I dag
I dag: Gårdagens status
Nattliga batchöverföringar gör att kundtjänst, planering och ekonomi ser olika och inaktuella versioner av samma order. En kund som frågar var leveransen är får vänta på att bli uppringd.
Med systemet
Med systemet: En aktuell status
Varje order eller ärende har en tidslinje som byggs av händelserna i alla system den passerar. Kundtjänst, planering och ekonomi ser samma fakta, och det gör även en assistent för kund- och medborgarservice som svarar på statusfrågor.
I dag
I dag: Undantag hanteras i inkorgar
Brist i lager, prisavvikelser, misslyckade leveranser och avvisade e-fakturor löses via e-post och kalkylblad, och i efterhand kan ingen säga vem som beslutade vad.
Med systemet
Med systemet: Undantag kommer med ett förslag
En agent samlar in uppgifterna bakom varje undantag och föreslår en åtgärd. En människa godkänner, ändrar eller avvisar förslaget i en gemensam undantagskö, och beslutet registreras.
I dag
I dag: Grunddata som inte stämmer överens
Samma kund, leverantör, artikel eller pris finns i flera system med olika värden, och ingen ansvarar för vilket värde som gäller.
Med systemet
Med systemet: En ägare per dataobjekt
Kunder, leverantörer, artiklar och priser har var sitt överenskommet ägande system och en namngiven ägare. Dubbletter och konflikter rapporteras till ägaren i stället för att rättas i tysthet längre fram i kedjan.
I dag
I dag: Varje förändring ger ett nytt gränssnitt
En ny försäljningskanal, marknadsplats eller juridisk enhet kräver ännu en punkt-till-punkt-koppling. E-fakturor till offentliga köpare och regler för e-faktura i andra länder lägger dessutom till format och nätverk i varje process.
Med systemet
Med systemet: Nya kopplingar återanvänder samma kontrakt
En ny kanal, en ny enhet eller ett nytt nätverk för e-faktura kopplas en gång till dokumenterade API:er och händelser, i stället för till varje system för sig.
Arbetsflöde
Så fungerar arbetsflödet
När data är korrekta behövs inget manuellt arbete i huvudflödet. När en order, en leverans eller en faktura avviker för undantagsloopen den till en människa med underlag och förslag, och den godkända 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: exempel på arbetsflöde med undantagsloop
Läs diagrammet som text
Huvudflödet går från att en affärshändelse registreras en gång i det ägande systemet, via att den sprids till övriga system genom API:er och händelser och att en tidslinje byggs per order, till fakturering, matchning och betalning. Det slutar med att processägarna följer upp flödet och åtgärdar orsakerna till undantagen.
När ett steg misslyckas, blir försenat eller hamnar utanför toleransen lämnar undantaget huvudflödet efter tidslinjesteget. En agent samlar in underlaget och föreslår en åtgärd, och en människa godkänner, ändrar eller avvisar den. Den godkända åtgärden genomförs i det ägande systemet och går 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 åtagande mot en kund görs utan en människa.
01
Steg 1: Registrera händelsen en gångSystem
En kundorder från webbutiken, en marknadsplats, EDI eller säljteamet, en inköpsorder eller ett serviceärende skapas i det system som äger uppgiften. Systemet publicerar en affärshändelse i ett CloudEvents-kuvert, beskriven i ett AsyncAPI-kontrakt. Order och leverantörsfakturor på papper eller som pdf går först genom dokumenttolkning.
02
Steg 2: Sprid via API:er och händelserSystem
Integrationslagret levererar händelsen till lager-, transport-, ekonomi- och CRM-systemen via deras dokumenterade API:er (OpenAPI). Mottagarna är idempotenta, så ett upprepat meddelande skapar aldrig en andra sändning eller faktura, och meddelanden som inte kan levereras väntar i en felkö tills de körs om.
03
Steg 3: En tidslinje per orderSystem
Statushändelser från alla system (bekräftad, plockad, skickad, levererad, fakturerad, betald) kopplas samman på affärsreferensen till en tidslinje. Regler för milstolpar och toleranser skapar ett undantag när ett steg misslyckas, blir försenat eller inte stämmer: brist i lager, ett pris utanför avtalad tolerans, en misslyckad leverans, en avvisad e-faktura.
04
Steg 4: Samla underlag och föreslåAI-agent
För varje undantag läser en agent det den behöver ur de berörda systemen: ordern, lagersaldon, prisavtalet, transportörens status och kundens villkor. Den föreslår en åtgärd med motivering och de uppgifter den har använt, till exempel en ersättningsartikel, ett rättat pris, en ny leveranstid eller en rättad faktura.
Undantagsflöde: Steg misslyckat eller utanför tolerans
05
Steg 5: Godkänn inom gränsvärdenMänniska
En medarbetare inom kundtjänst, logistik eller ekonomi ser undantaget, underlaget och förslaget i undantagskön och godkänner, ändrar eller avvisar det. Den godkända åtgärden genomförs via API:et i det ägande systemet, som publicerar ändringen som en ny händelse.
Undantagsflöde: Steg misslyckat eller utanför tolerans· Återgår till steg 2
Mänsklig kontrollpunkt
Agenter bokför aldrig ekonomiska transaktioner, ändrar aldrig priser eller kreditgränser och lovar aldrig något till en kund utan godkännande. Gränsvärden per typ av åtgärd avgör vem som godkänner, och varje förslag och beslut loggas.
06
Steg 6: Fakturera, matcha och betalaSystem
Utgående fakturor lämnar affärssystemet som e-fakturor (Peppol BIS Billing 3.0, EN 16931) via en accesspunkt. Inkommande leverantörsfakturor matchas mot inköpsorder och inleveranser och går till attest när de avviker, och betalstatus från banken eller betaltjänsten stänger tidslinjen.
07
Steg 7: Följ upp och åtgärda orsakerMänniska
Processägarna och integrationsteamet går med fast rytm igenom undantag per orsak, gränssnittsfel och konflikter i grunddata. De åtgärdar orsaken där den finns, i en grunddatapost, en toleransregel eller en mappning, i stället för att lösa samma undantag igen.
Komponenter
Det här skulle vi bygga
01
Händelsestyrt integrationslager
API:er och händelser som utgår från kontrakt mellan affärssystem, CRM, e-handel, lager, transport och ekonomi, specificerade i OpenAPI och AsyncAPI med CloudEvents-kuvert, på den integrationsplattform du redan har eller byggda molnbaserat.
Ett överenskommet ägande system och en ägare per dataobjekt, matchningsregler för kunder, leverantörer och artiklar och rapporter om dubbletter och konflikter till dem som äger uppgifterna.
En tjänst som kopplar ihop händelser till en tidslinje per order eller ärende, tillämpar regler för milstolpar och toleranser och visar flöde och undantag för processägarna.
En kö med undantag som visar det insamlade underlaget och agentens förslag, med åtgärderna godkänn, ändra och avvisa och gränsvärden per typ av åtgärd som kontrolleras där åtgärden genomförs.
Fakturor enligt Peppol BIS Billing 3.0 och EN 16931 i UBL, som skickas och tas emot via en accesspunkt och valideras före sändning, med avvisade fakturor till undantagskön och attestflöden i ekonomisystemet.
Hälsoövervakning och larm per gränssnitt, driftrutiner för driftteamet och kontrollerad omkörning av misslyckade meddelanden, driftsatt med infrastruktur som kod i din molnmiljö.
Inköpsorder och orderbekräftelser från leverantörer
Serviceärenden och servicerapporter från fält
Spårning och leveranshändelser från transportörer
E-fakturor och statussvar via Peppol
Kontoutdrag och betalningsaviseringar
Lösningens kärna
Sammankopplade processer
System som lösningen samverkar med
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 transportörers API:er
System för lager- och transportstyrning
Peppol-accesspunkt, banker och betaltjänster
Produktinformationssystem och dataplattformen
Kontroller
Inbyggda kontroller
Åtkomstgränser
Varje integration och agenten körs under en egen tjänsteidentitet per system, begränsad till de API-anrop som behövs. Agenten får läsa i flera system för att samla underlag, men kan bara skriva via en kort lista godkända åtgärder som genomförs via det ägande systemets API och aldrig via direkt databasåtkomst.
Mänsklig granskning
Gränsvärden sätts per typ av åtgärd tillsammans med processägaren: vad agenten bara får föreslå, vad en medarbetare godkänner och vad som kräver en andra godkännare. Bokföring, ändrade priser och kreditgränser och åtaganden mot kunder väntar alltid på en människa, och leverantörsfakturor attesteras enligt din attestordning. Åtgärder med liten påverkan som går att ångra, till exempel att köra om ett misslyckat meddelande, kan köras utan godkännande om ägaren går med på det.
Spårbarhet
Varje händelse, förslag, godkännande, avvisning och genomförd åtgärd loggas mot order- eller ärendereferensen, med de uppgifter agenten använde, modell- och promptversion och vem som godkände. En omtvistad faktura eller ett kundklagomål kan spåras steg för steg.
Dataskydd
Kontaktuppgifter till kunder och leverantörer går bara till de system som behöver dem. Tidslinjen lagrar affärsreferenser och status i stället för fullständiga poster, och loggar sparas enligt den lagringstid du bestämmer. Behandlingen sker i den region som har avtalats.
Transparens kring AI
Agentens förslag är märkta som sådana i undantagskön, med underlag och motivering bredvid. De ägande systemen förblir auktoritativa: tidslinjen visar vad de rapporterar och skriver aldrig över dem.
Mått
Det här skulle vi mäta
Vi kommer överens med dig om måtten under förstudien och tar utgångsläget ur dina nuvarande system- och gränssnittsloggar innan något ändras.
Det här skulle vi mäta
Mått
Varför det är viktigt
Så skulle vi mäta det
01Ledtid per order
Varför det är viktigtDet mått som kunderna märker först och som visar var ordrarna väntar.
Så skulle vi mäta detTid från mottagen order till leverans och till betalning, per kanal och bolag, ur tidslinjens händelser.
02Order utan manuell hantering
Varför det är viktigtVisar hur stor del av flödet som går på korrekta data och överenskomna regler.
Så skulle vi mäta detAndel order och ärenden som når betalning utan något manuellt steg eller undantag, ur tidslinjen.
03Undantag per orsak och tid till lösning
Varför det är viktigtVisar vilka orsaker som ska åtgärdas först och om undantagskön hinner med.
Så skulle vi mäta detAntal undantag per orsakskod och tid från upptäckt till genomförd åtgärd, ur undantagsköns loggar.
04Andel avvisade e-fakturor
Varför det är viktigtAvvisade fakturor försenar betalningen och pekar oftast på fel i grunddata eller mappningar.
Så skulle vi mäta detAndel skickade och mottagna e-fakturor som avvisas, per orsak, ur accesspunktens svar.
05Gränssnittsfel och återställningstid
Varför det är viktigtVisar om integrationslagret är tillförlitligt och om fel upptäcks och åtgärdas snabbt.
Så skulle vi mäta detMisslyckade meddelanden per gränssnitt och tid från fel till lyckad omkörning, ur integrationsövervakningen.
06Dubbletter och konflikter i grunddata
Varför det är viktigtDe flesta undantag går att spåra till uppgifter som skiljer sig mellan system.
Så skulle vi mäta detÖppna dubbletter och motstridiga värden per dataobjekt och system, ur matchningsrapporterna.
Vi sätter inga mål förrän utgångsläget har mätts.
Införande
Så skulle vi införa det
Fas 01
Förstudie och processkarta
En process, till exempel order till betalning för en försäljningskanal, och en typ av undantag. Vi kartlägger system, gränssnitt, dataägare och hur undantag hanteras i dag.
Kriterier för att gå vidare
Process, system och dataägare kartlagda
Första typen av undantag och gränsvärden för godkännande överenskomna
Utgångsläge hämtat ur nuvarande loggar
Fas 02
Integration och tidslinje
Dokumenterade API:er och händelser för de system som ingår, och tidslinjen i drift vid sidan av de befintliga gränssnitten utan att ändra dem.
Kriterier för att gå vidare
Händelsekontrakt publicerade och versionshanterade
Tidslinjen stämmer med de ägande systemen i ett urval order
Omkörning och driftrutiner testade
Fas 03
Pilot med undantagskön
Agenten föreslår åtgärder för den valda typen av undantag och människor godkänner varje förslag. Vi jämför förslagen med det medarbetarna själva hade gjort.
Kriterier för att gå vidare
Förslagens kvalitet uppfyller de överenskomna kriterierna
Gränsvärden och godkännare satta per typ av åtgärd
Spårbarheten granskad av ekonomi och internkontroll
Fas 04
Bygg ut och avveckla
Fler typer av undantag, kanaler, bolag och processer, till exempel inköp till betalning, alla på samma kontrakt. Gamla punkt-till-punkt-kopplingar stängs av en i taget.
Kriterier för att gå vidare
Varje nytt flöde på samma kontrakt och övervakning
Kundorderstyrd tillverkning och reservdelsorder hos en underleverantör till fordonsindustrin, från affärssystemet till lager och transportörer, med leverantörsbekräftelser och e-fakturor matchade mot inköpsorder.
Beställningar av anslutning och installation hos ett energibolag, följda från arbetsorder via fältbesök till faktura, och material som avropas från ramavtal.
Arbetsordrar för underhåll, inköpsorder till entreprenörer och deras fakturor, följda från beställning till betalning hos en regional kollektivtrafikmyndighet eller ett kommunalt hamnbolag.
Inköp till betalning med e-fakturor till och från offentliga köpare via Peppol, matchade mot beställning och inleverans och attesterade före betalning.
Illustrativt exempel
Inköp till betalning i en region
Utgångsläge
En region tar emot leverantörsfakturor som e-fakturor via Peppol och som pdf från mindre leverantörer. Beställningar görs i flera system, inleveranser registreras inte alltid och fakturor som inte matchar skickas runt för attest via e-post.
System
Beställningar, inleveranser och fakturor flödar som händelser mellan e-handelssystemet, ekonomisystemet och lagret, och varje beställning har en tidslinje. E-fakturor matchas mot beställning och inleverans, och pdf-fakturor går först genom dokumenttolkning.
Mänsklig kontroll
Avvikelser i pris, kvantitet eller leverans hamnar i en undantagskö där en agent föreslår en åtgärd. Attestanten enligt regionens attestordning godkänner varje faktura som avviker, och betalningar görs bara från ekonomisystemet.
Det här skulle vi mäta
Andel fakturor som matchas utan manuell hantering, undantag per orsak och tid till lösning, och andel avvisade e-fakturor.
Sverige
E-faktura, attest och flera länder i samma flöde
Leverantörer har skickat e-fakturor enligt europeisk standard till offentliga köpare sedan den 1 april 2019 (lag 2018:1277), och statliga myndigheter ska kunna skicka och ta emot e-fakturor via Peppol. Sedan den 1 juli 2026 är Upphandlingsmyndigheten Peppol Authority i Sverige. Något inhemskt krav mellan företag finns inte, men från den 1 juli 2030 blir e-faktura obligatorisk för gränsöverskridande transaktioner inom EU. Svenska koncerner har ofta bolag i flera nordiska länder och EU-länder, så vi lägger varje lands format och nätverk bakom samma händelser: ett nytt krav blir en ny koppling, inte en ny process.
Dataförordningen, som tillämpas sedan den 12 september 2025, har regler för byte av databehandlingstjänster, så vi håller händelsekontrakt och dataexporter flyttbara. Agenterna i undantagskön utformas med AI-förordningen i åtanke, och integrationerna levereras med loggad åtkomst och dokumenterade komponenter för kunder som omfattas av cybersäkerhetslagen (2025:1506) och ska visa säkerhet i leveranskedjan.
Nej. Affärssystemet, CRM-systemet, webbutiken och lagersystemet sköter var sin uppgift. Vi integrerar runt de ägande systemen, kommer överens om vilket system som äger vilka uppgifter och ger processen en tidslinje genom dem alla. Där ett gammalt order- eller affärssystem hindrar förändring lägger modernisering av äldre system det först bakom API:er.
02Ersätter ni vår integrationsplattform?
Inte om den gör sitt jobb. Vi bygger på den integrationsplattform eller meddelandemäklare du redan har och lägger till kontrakt, övervakning och omkörning där det saknas. Finns ingen bygger vi molnbaserat. Läs mer om integrationer och API:er.
03Kan agenterna agera på egen hand?
Bara inom gränsvärden som du kommer överens om per typ av åtgärd, och bara för åtgärder med liten påverkan som går att ångra, till exempel att köra om ett misslyckat meddelande. Bokföring, priser, kreditgränser och åtaganden mot kunder kräver alltid en människa. Läs mer om när AI-agenter behöver mänskligt godkännande.
04Hur passar e-fakturan in?
Sedan den 1 april 2019 ska leverantörer skicka e-fakturor enligt europeisk standard (EN 16931) till upphandlande myndigheter och enheter, enligt lagen (2018:1277) om elektroniska fakturor till följd av offentlig upphandling. Upphandlingsmyndigheten, som sedan den 1 juli 2026 är Peppol Authority i Sverige, rekommenderar Peppol BIS Billing 3 via Peppolnätverket. Något inhemskt krav på e-faktura mellan företag finns inte; regeringen utreder hur EU-paketet om mervärdesskatt i den digitala tidsåldern (ViDA) ska genomföras, och utredningen ska redovisa senast den 30 november 2027. Från den 1 juli 2030 blir e-faktura och digital rapportering obligatoriska för gränsöverskridande transaktioner inom EU. Vi behandlar e-fakturan som ännu en händelse i processen: den skapas i affärssystemet, skickas via en accesspunkt och hanteras i undantagskön om den avvisas. Läs guiden om e-faktura och Peppol i Sverige.
05Hur undviker ni ännu ett skört nät av punkt-till-punkt-kopplingar?
Systemen publicerar och tar emot dokumenterade händelser och API:er via ett lager, inte via direkta kopplingar till varandra. Kontrakten versionshanteras, mottagarna är idempotenta, misslyckade meddelanden kan köras om och varje flöde har en namngiven ägare. En ny kanal prenumererar på befintliga händelser i stället för att kopplas till varje system.
06Var börjar vi?
Med en process och en typ av undantag, till exempel order till betalning för en försäljningskanal med brist i lager som första undantag. Det visar att händelserna, tidslinjen och godkännandeflödet fungerar innan mer läggs till. Vårt arbetssätt beskriver hur vi levererar.
Berätta om dina order- och fakturaflöden
Välj en process och de bolag och länder den omfattar. Vi kartlägger system, gränssnitt och undantag tillsammans med dig och föreslår en första version, med e-faktura och attest på plats från början.