Hver ordre på én tidslinje, fra modtagelse til betalt faktura.
Order to cash, procure to pay og forløbet fra serviceopgave til faktura løber gennem ERP, CRM, webshop, lager, transport og økonomi. Vi forbinder systemerne med dokumenterede API’er og hændelser, giver hver ordre én status på tværs af dem og sender hver undtagelse til en agent, der forbereder en løsning, som en person godkender.
For virksomheder og myndigheder, der sælger, køber og fakturerer på tværs af mange systemer, fragtfirmaer og formater til e-fakturering.
En salgsordre, en indkøbsordre eller en serviceopgave registreres én gang i sit kildesystem og fordeles til de andre systemer via dokumenterede API’er og hændelser. Statushændelser bygger én tidslinje pr. ordre. Når et trin fejler eller falder uden for tolerancen, samler en agent sammenhængen og foreslår en løsning, som en person godkender, før den udføres i kildesystemet. Fakturaer udveksles og matches som strukturerede e-fakturaer, og procesejerne gennemgår flowet og integrationernes tilstand.
Før og efter
Det ændrer sig i den daglige drift
I dag
Med systemet
I dag
I dag: Tastet igen ved hver overlevering
En ordre fra webshoppen eller salgsteamet tastes igen i ERP-systemet, og leverings- og fakturaoplysninger kopieres i hånden over i lager-, transport- og økonomisystemerne.
Med systemet
Med systemet: Registreret én gang, brugt overalt
Hver ordre, levering og faktura oprettes i det system, der ejer den, og offentliggøres som en hændelse. De andre systemer abonnerer på hændelsen i stedet for at taste den igen.
I dag
I dag: Gårsdagens status
Natlige batchintegrationer betyder, at kundeservice, planlægning og økonomi hver ser en forskellig og forældet status for den samme ordre. En kunde, der spørger, hvor en levering er, må vente på at blive ringet op.
Med systemet
Med systemet: Én aktuel status
Hver ordre eller opgave har én tidslinje, bygget af hændelserne fra alle de systemer, den passerer. Kundeservice, planlægning og økonomi ser de samme fakta, og det kan en assistent i kundeservice, der besvarer spørgsmål om status, også.
I dag
I dag: Undtagelser i indbakker
Manglende lager, prisforskelle, mislykkede leveringer og afviste e-fakturaer løses via mail og regneark, og ingen kan bagefter se, hvem der besluttede hvad.
Med systemet
Med systemet: Undtagelser kommer med et forslag
En agent samler data bag hver undtagelse og foreslår en løsning. En person godkender, redigerer eller afviser den på ét undtagelsesbord, og beslutningen registreres.
I dag
I dag: Stamdata, der ikke stemmer
Den samme kunde, leverandør, vare eller pris findes i flere systemer med forskellige værdier, og ingen har ansvaret for, hvilken der er rigtig.
Med systemet
Med systemet: Én ejer pr. dataobjekt
Kunder, leverandører, varer og priser har hver et aftalt kildesystem og en navngiven ejer. Dubletter og konflikter rapporteres til ejeren og rettes ikke i stilhed længere nede i kæden.
I dag
I dag: Hver ændring giver en ny integration
En ny salgskanal, markedsplads eller juridisk enhed betyder endnu en punkt til punkt-forbindelse. Krav om e-fakturering lægger desuden et struktureret format og et netværk oven i hver proces.
Med systemet
Med systemet: Nye forbindelser genbruger de samme kontrakter
En ny kanal, en ny enhed eller et nyt netværk til e-fakturering forbindes én gang til dokumenterede API’er og hændelser i stedet for til hvert system for sig.
Forløb
Sådan kører forløbet
Når data er rene, kræver hovedforløbet intet manuelt arbejde. Når en ordre, en levering eller en faktura afviger, bringer undtagelsessløjfen den til en person med dokumentationen og et forslag, og den godkendte rettelse løber tilbage gennem det samme integrationslag.
Eksempel på et forløb
7 trin · 1 menneskelig kontrol
Signaturforklaring
System
AI-agent
Person
Menneskelig kontrol
Undtagelsesforløb
Sammenhængende processer: eksempel på et forløb med undtagelsessløjfe
Læs diagrammet som tekst
Hovedforløbet går fra at registrere en forretningshændelse én gang i kildesystemet, over fordeling til de andre systemer via API’er og hændelser og en tidslinje pr. ordre, til fakturering, matchning og afstemning. Det slutter med, at procesejerne gennemgår flowet og retter årsagerne til undtagelser.
Når et trin fejler, bliver forsinket eller falder uden for tolerancen, forlader undtagelsen hovedforløbet efter tidslinjetrinnet. En agent samler sammenhængen og foreslår en løsning, og en person godkender, redigerer eller afviser den. Den godkendte handling udføres i kildesystemet og vender tilbage til fordelingstrinnet som en ny hændelse.
Godkendelsen er den menneskelige kontrol: ingen finansiel bogføring, ingen ændring af pris eller kreditgrænse og intet tilsagn til en kunde sker uden en person.
01
Trin 1: Registrér hændelsen én gangSystem
En salgsordre fra webshoppen, en markedsplads, EDI eller salgsteamet, en indkøbsordre eller en serviceopgave oprettes i det system, der ejer den. Systemet offentliggør en forretningshændelse i en CloudEvents-kuvert, beskrevet i en AsyncAPI-kontrakt. Ordrer og leverandørfakturaer på papir eller som pdf går først gennem dokumentbehandling.
02
Trin 2: Fordel via API’er og hændelserSystem
Integrationslaget leverer hændelsen til lager-, transport-, økonomi- og CRM-systemerne via deres dokumenterede API’er (OpenAPI). Modtagerne er idempotente, så en gentaget besked aldrig skaber en ekstra forsendelse eller faktura, og beskeder, der ikke kan leveres, venter i en fejlkø, så de kan sendes igen.
03
Trin 3: Byg én tidslinje pr. ordreSystem
Statushændelser fra alle systemer (bekræftet, plukket, afsendt, leveret, faktureret, betalt) samles på forretningsreferencen til én tidslinje. Regler for milepæle og tolerancer rejser en undtagelse, når et trin fejler, bliver forsinket eller ikke stemmer: manglende lager, en pris uden for den aftalte tolerance, en mislykket levering, en afvist e-faktura.
04
Trin 4: Saml sammenhængen og foreslåAI-agent
For hver undtagelse læser en agent det, den har brug for, i de involverede systemer: ordren, lagerbeholdningen, prisaftalen, fragtfirmaets status og kundens betingelser. Den foreslår en løsning med sin begrundelse og de data, den har brugt, for eksempel en erstatningsvare, en rettet pris, en ny leveringsdato eller en rettet faktura.
Undtagelsesforløb: Trin fejlet eller uden for tolerance
05
Trin 5: Godkend inden for tærsklerPerson
En medarbejder i kundeservice, logistik eller økonomi ser undtagelsen, dokumentationen og forslaget på undtagelsesbordet og godkender, redigerer eller afviser det. Den godkendte handling udføres via kildesystemets API, og systemet offentliggør ændringen som en ny hændelse.
Undtagelsesforløb: Trin fejlet eller uden for tolerance· Fortsætter ved trin 2
Menneskelig kontrol
Agenter bogfører aldrig finansielle transaktioner, ændrer priser eller kreditgrænser eller giver kunden tilsagn uden godkendelse. Tærskler pr. handlingstype afgør, hvem der godkender, og hvert forslag og hver beslutning logges.
06
Trin 6: Fakturér, match og afstemSystem
Udgående fakturaer forlader ERP-systemet som strukturerede e-fakturaer i OIOUBL eller Peppol BIS (EN 16931), til offentlige kunder via NemHandel. Indgående leverandørfakturaer matches med indkøbsordrer og varemodtagelser, og betalingsstatus fra banken eller betalingsudbyderen lukker tidslinjen.
07
Trin 7: Gennemgå flowet og ret årsagernePerson
Procesejere og integrationsteamet gennemgår med fast rytme undtagelser efter årsag, fejl i integrationer og konflikter i stamdata. De retter årsagen, hvor den sidder, i en stamdatapost, en toleranceregel eller en mapping, i stedet for at løse den samme undtagelse igen.
Komponenter
Det ville vi bygge
01
Hændelsesdrevet integrationslag
Kontraktbaserede API’er og hændelser mellem ERP, CRM, webshop, lager, transport og økonomi, specificeret i OpenAPI og AsyncAPI med CloudEvents-kuverter, på din eksisterende integrationsplatform eller bygget cloud native.
Et aftalt kildesystem og en ejer pr. dataobjekt, matchningsregler for kunder, leverandører og varer og rapporter om dubletter og konflikter til de personer, der ejer dem.
En tjeneste, der samler hændelser til én tidslinje pr. ordre eller opgave, anvender regler for milepæle og tolerancer og viser flow og undtagelser for procesejerne.
En kø af undtagelser med den samlede sammenhæng og agentens forslag, med handlingerne godkend, redigér og afvis og med tærskler for godkendelse pr. handlingstype, som håndhæves der, hvor handlingen udføres.
Fakturaer i OIOUBL og Peppol BIS (EN 16931), sendt og modtaget via NemHandel eller et Peppol-adgangspunkt og valideret før afsendelse, med afviste fakturaer sendt til undtagelsesbordet.
Overvågning og alarmer for hver integration, driftsvejledninger til driftsteamet og kontrolleret genafsendelse af fejlede beskeder, udrullet med infrastruktur som kode i dit eget cloudmiljø.
NemHandel, Peppol-adgangspunkt, banker og betalingsudbydere
Produktinformation (PIM) og dataplatformen
Kontroller
Indbyggede kontroller
Adgangsgrænser
Hver integration og agenten kører under deres egen tjenesteidentitet pr. system, begrænset til de API-operationer, de har brug for. Agenten må læse på tværs af systemer for at samle sammenhængen, men kan kun skrive via en kort liste af godkendte handlinger, der udføres af kildesystemets API og aldrig ved direkte adgang til databasen.
Menneskelig gennemgang
Tærskler for godkendelse fastsættes pr. handlingstype sammen med procesejeren: hvad agenten kun må foreslå, hvad et teammedlem godkender, og hvad der kræver en ekstra godkender. Finansielle bogføringer, ændringer af priser og kreditgrænser og tilsagn til kunder venter altid på en person. Handlinger med lille betydning, der kan rulles tilbage, for eksempel at sende en fejlet besked igen, kan køre uden godkendelse, hvis ejeren er enig.
Sporbarhed
Hver hændelse, hvert forslag, hver godkendelse, afvisning og udført handling logges på ordrens eller opgavens reference, med de data, agenten brugte, model- og promptversionen og den, der godkendte. En omstridt faktura eller en kundeklage kan spores trin for trin.
Databeskyttelse
Kontaktoplysninger om kunder og leverandører sendes kun til de systemer, der har brug for dem. Tidslinjen gemmer forretningsreferencer og status frem for hele poster, og logs følger den opbevaringsperiode, du fastsætter. Behandlingen foregår i den aftalte region.
Gennemsigtighed om AI
Agentens forslag er markeret som sådan på undtagelsesbordet, med dokumentation og begrundelse ved siden af. Kildesystemerne er fortsat autoritative: tidslinjen viser, hvad de rapporterer, og overskriver dem aldrig.
Målepunkter
Det ville vi måle
Målepunkterne aftaler vi med dig i analysefasen, og baseline tager vi fra dine nuværende system- og integrationslogs, før noget ændres.
Det ville vi måle
Målepunkt
Hvorfor det er vigtigt
Sådan ville vi måle det
01Ordrens gennemløbstid
Hvorfor det er vigtigtDet mål, kunderne mærker først, og det, der viser, hvor ordrerne venter.
Sådan ville vi måle detTid fra modtaget ordre til levering og til betaling, pr. kanal og enhed, ud fra hændelserne på tidslinjen.
02Ordrer uden manuel håndtering
Hvorfor det er vigtigtViser, hvor stor en del af flowet der kører på rene data og aftalte regler.
Sådan ville vi måle detAndelen af ordrer og opgaver, der når betaling uden manuelle trin eller undtagelser, ud fra tidslinjen.
03Undtagelser efter årsag og tid til løsning
Hvorfor det er vigtigtFortæller dig, hvilke årsager der skal rettes først, og om undtagelsesbordet kan følge med.
Sådan ville vi måle detAntal undtagelser pr. årsagskode og tid fra opdagelse til udført løsning, ud fra undtagelsesbordets logs.
04Andel afviste e-fakturaer
Hvorfor det er vigtigtAfviste fakturaer forsinker betalingen og skyldes som regel fejl i stamdata eller mapping.
Sådan ville vi måle detAndelen af sendte og modtagne e-fakturaer, der afvises, fordelt på årsag, ud fra kvitteringerne fra netværket.
05Fejl i integrationer og tid til genopretning
Hvorfor det er vigtigtViser, om integrationslaget er pålideligt, og om fejl bliver opdaget og rettet hurtigt.
Sådan ville vi måle detFejlede beskeder pr. integration og tid fra fejl til vellykket genafsendelse, ud fra overvågningen af integrationerne.
06Dubletter og konflikter i stamdata
Hvorfor det er vigtigtDe fleste undtagelser kan spores tilbage til data, der er forskellige fra system til system.
Sådan ville vi måle detÅbne dubletter og modstridende værdier pr. dataobjekt og system, ud fra matchningsrapporter.
Vi sætter ingen mål, før der er en baseline.
Udrulning
Sådan ville vi rulle det ud
Fase 01
Analyse og proceskort
Én proces, for eksempel order to cash for én salgskanal, og én type undtagelse. Vi kortlægger systemer, integrationer, dataejere og den måde, undtagelser håndteres på i dag.
Kriterier for at gå videre
Proces, systemer og dataejere kortlagt
Første type undtagelse og tærskler for godkendelse aftalt
Baseline taget fra de nuværende logs
Fase 02
Integration og tidslinje
Dokumenterede API’er og hændelser for de systemer, der er med, og tidslinjen kørende ved siden af de eksisterende integrationer uden at ændre dem.
Kriterier for at gå videre
Hændelseskontrakter offentliggjort og versioneret
Tidslinjen stemmer med kildesystemerne i en stikprøve af ordrer
Genafsendelse og driftsvejledninger testet
Fase 03
Pilot med undtagelsesbordet
Agenten foreslår løsninger for den valgte type undtagelse, og medarbejderne godkender hvert forslag. Vi sammenligner forslagene med det, medarbejderne selv ville have gjort.
Kriterier for at gå videre
Forslagenes kvalitet opfylder de aftalte kriterier
Tærskler og godkendere fastsat pr. handlingstype
Revisionssporet gennemgået af økonomi og intern kontrol
Fase 04
Udvid og udfas
Flere typer undtagelser, kanaler, enheder og processer som procure to pay, alle på de samme kontrakter. Gamle punkt til punkt-integrationer slukkes én ad gangen.
Kriterier for at gå videre
Hvert nyt flow på de samme kontrakter og den samme overvågning
Ordrer på kundetilpassede produkter og reservedele fra ERP-systemet til lageret og fragtfirmaerne, med ordrebekræftelser og e-fakturaer fra leverandører matchet med indkøbsordrer.
Anmodninger om tilslutning og installation hos et forsyningsselskab, fulgt fra arbejdsordre over besøg hos kunden til faktura, og materialer købt ind under faste indkøbsaftaler.
Arbejdsordrer på vedligeholdelse, indkøbsordrer til entreprenører og deres fakturaer, fulgt fra anmodning til betaling i havne og i den kommunale vejdrift.
Procure to pay, hvor e-fakturaer, som offentlige myndigheder modtager via NemHandel, matches med ordrer og varemodtagelser før betaling.
Eksempel
En grossist med kunder i tre lande
Situation
En grossist i tekniske artikler sælger via webshop, en markedsplads og eget salgsteam i Danmark, Sverige og Tyskland fra to lagre. Ordrer tastes igen i ERP-systemet, fragtfirmaer melder leveringsproblemer på mail, og fakturaer til kommuner og regioner skal sendes via NemHandel.
System
Ordrer, lager, forsendelser og fakturaer løber som hændelser mellem webshoppen, ERP-systemet, lagersystemet og fragtfirmaerne, og hver ordre har én tidslinje. Fakturaer sendes som strukturerede e-fakturaer i det format og via det netværk, hver kunde og hvert land kræver, og til offentlige kunder i Danmark via NemHandel.
Menneskelig kontrol
Manglende lager og mislykkede leveringer lander på ét undtagelsesbord, hvor en agent foreslår en erstatningsvare eller en ny leveringsdato. Kundeservice godkender hvert forslag; prisændringer og kreditnotaer kræver godkendelse fra økonomi.
Det ville vi måle
Andel ordrer uden manuel håndtering pr. land og kanal, undtagelser efter årsag og tid til løsning og andel afviste e-fakturaer pr. land.
Danmark
Én proces, danske og europæiske krav
Offentlige myndigheder i Danmark kræver e-fakturaer via NemHandel i OIOUBL eller Peppol BIS, og efter bogføringsloven skal registrerede digitale bogføringssystemer understøtte begge formater. Erhvervsstyrelsen planlægger at erstatte OIOUBL med Nemhandel BIS 4 i løbet af 2028 til 2029, og EU’s ViDA-pakke gør struktureret e-fakturering til standard for B2B-leverancer inden for EU fra 1. juli 2030. Vi designer ét integrationslag, hvor hvert lands format og netværk ligger bag de samme hændelser, så et nyt krav betyder en ny forbindelse og ikke en ny proces.
Dataforordningen, der har fundet anvendelse siden 12. september 2025, fastsætter regler for skift mellem databehandlingstjenester, så vi holder hændelseskontrakter og dataudtræk flytbare. Agenterne på undtagelsesbordet designes efter AI-forordningen, og integrationerne leveres med logget adgang og dokumenterede komponenter til kunder, der efter NIS 2-loven skal kunne vise sikkerhed i forsyningskæden.
Nej. Dit ERP-system, dit CRM, din webshop og dit lagersystem gør hver deres arbejde. Vi integrerer omkring disse kildesystemer, aftaler, hvilket system der ejer hvilke data, og giver processen én tidslinje på tværs af dem. Hvor et gammelt ordre- eller ERP-system blokerer for forandring, lægger modernisering af legacy det først bag API’er.
02Udskifter I vores integrationsplatform?
Ikke hvis den gør sit arbejde. Vi bygger på den integrationsplatform eller message broker, du allerede har, og tilføjer kontrakter, overvågning og genafsendelse, hvor de mangler. Hvor der ingen platform er, bygger vi cloud native. Læs mere om vores arbejde med integrationer.
03Kan agenter handle på egen hånd?
Kun inden for tærskler, du aftaler pr. handlingstype, og kun for handlinger med lille betydning, der kan rulles tilbage, for eksempel at sende en fejlet besked igen. Finansielle bogføringer, priser, kreditgrænser og tilsagn til kunder kræver altid en person. Læs, hvor AI-agenter har brug for menneskelig godkendelse.
04Hvordan passer e-fakturering ind?
Offentlige myndigheder i Danmark kræver e-fakturaer via NemHandel i OIOUBL eller Peppol BIS, og efter bogføringsloven skal registrerede digitale bogføringssystemer understøtte begge formater. Fra 1. januar 2026 gælder digital bogføring for virksomheder uden for årsregnskabsloven med en nettoomsætning over 300.000 kr. i to år i træk. Erhvervsstyrelsen planlægger at erstatte OIOUBL med Nemhandel BIS 4 i løbet af 2028 til 2029, og EU’s pakke om moms i den digitale tidsalder (ViDA) gør struktureret e-fakturering til standard for B2B-leverancer inden for EU fra 1. juli 2030. Vi behandler e-fakturaen som endnu en hændelse i processen: udstedt fra ERP-systemet, sendt via netværket og håndteret på undtagelsesbordet, hvis den bliver afvist. Se vores guide til e-fakturering.
05Hvordan undgår I endnu et skrøbeligt net af punkt til punkt-forbindelser?
Systemerne offentliggør og bruger dokumenterede hændelser og API’er gennem ét lag, ikke via direkte forbindelser til hinanden. Kontrakterne er versionerede, modtagerne er idempotente, fejlede beskeder kan sendes igen, og hvert flow har en navngiven ejer. En ny kanal abonnerer på eksisterende hændelser i stedet for at få en forbindelse til hvert system.
06Hvad er et godt første omfang?
Én proces og én type undtagelse, for eksempel order to cash for én salgskanal med manglende lager som første undtagelse. Det afprøver hændelserne, tidslinjen og godkendelsesforløbet, før mere kommer til. Læs om vores måde at levere på.
Lad os se på dine ordre- og fakturaflows
Vælg én proces og de selskaber, den kører i. Vi kortlægger systemer, integrationer og undtagelser sammen med dig og foreslår en første version, der virker på tværs af dine selskaber.