Elke order op één tijdlijn, van intake tot betaalde factuur.
Order-to-cash, procure-to-pay en het traject van serviceaanvraag tot factuur lopen door ERP-, CRM-, e-commerce-, magazijn-, transport- en financiële systemen. Wij koppelen die systemen met gedocumenteerde API’s en events, geven elke order één status over al die systemen heen, en sturen elke uitzondering naar een agent die een oplossing voorbereidt die een mens goedkeurt.
Voor Belgische ondernemingen die verkopen, aankopen en factureren over meerdere systemen heen, nu gestructureerde e-facturatie tussen ondernemingen verplicht is.
07De doorstroming bekijken en oorzaken wegnemenPersoon
Een verkooporder, inkooporder of serviceaanvraag wordt één keer vastgelegd in het bronsysteem en via gedocumenteerde API’s en events naar de andere systemen verspreid. Statusevents vormen één tijdlijn per order. Mislukt een stap of valt hij buiten de tolerantie, dan verzamelt een agent de context en stelt hij een oplossing voor, die een mens goedkeurt voordat ze in het bronsysteem wordt uitgevoerd. Facturen worden als gestructureerde e-facturen uitgewisseld en gematcht, en proceseigenaars bewaken de doorstroming en de gezondheid van de interfaces.
Voor en na
Wat er verandert in de dagelijkse operatie
Vandaag
Met het systeem
Vandaag
Vandaag: Bij elke overdracht opnieuw ingetypt
Een order uit de webshop of van het verkoopteam wordt opnieuw ingetypt in het ERP, en lever- en factuurgegevens worden met de hand overgenomen in de magazijn-, transport- en financiële systemen.
Met het systeem
Met het systeem: Eén keer ingevoerd, overal gebruikt
Elke order, levering en factuur wordt aangemaakt in het systeem dat er eigenaar van is en als event gepubliceerd. Andere systemen abonneren zich erop, in plaats van ze over te typen.
Vandaag
Vandaag: De status van gisteren
Door nachtelijke batchinterfaces zien klantenservice, planning en financiën elk een andere, verouderde stand van dezelfde order. Een klant die vraagt waar een levering blijft, wordt teruggebeld.
Met het systeem
Met het systeem: Eén actuele status
Elke order of aanvraag heeft één tijdlijn, opgebouwd uit de events van alle systemen die ze doorloopt. Klantenservice, planning en financiën kijken naar dezelfde feiten, net als een assistent voor klantcontact die statusvragen beantwoordt.
Vandaag
Vandaag: Uitzonderingen afgehandeld in mailboxen
Voorraadtekorten, prijsverschillen, mislukte leveringen en geweigerde e-facturen worden via e-mail en spreadsheets opgelost, en achteraf weet niemand wie wat heeft beslist.
Met het systeem
Met het systeem: Uitzonderingen komen met een voorstel
Een agent verzamelt de gegevens achter elke uitzondering en stelt een oplossing voor. Een mens keurt die goed, past ze aan of wijst ze af op één uitzonderingsdesk, en de beslissing wordt vastgelegd.
Vandaag
Vandaag: Stamgegevens die elkaar tegenspreken
Klanten, leveranciers, producten en prijzen staan in meerdere systemen met verschillende waarden, en niemand is ervoor verantwoordelijk welke waarde de juiste is.
Met het systeem
Met het systeem: Eén eigenaar per gegevensobject
Klanten, leveranciers, producten en prijzen hebben elk een afgesproken bronsysteem en een benoemde eigenaar. Duplicaten en conflicten worden aan die eigenaar gemeld, en niet stilzwijgend verderop in de keten rechtgezet.
Vandaag
Vandaag: Elke wijziging voegt een interface toe
Een nieuw verkoopkanaal, een marktplaats of een juridische entiteit betekent opnieuw een punt-tot-puntkoppeling. Nationale verplichtingen voor e-facturatie voegen daar per proces nog een gestructureerd formaat en een netwerk aan toe.
Met het systeem
Met het systeem: Nieuwe koppelingen hergebruiken dezelfde contracten
Een nieuw kanaal, een nieuwe entiteit of een nieuw netwerk voor e-facturatie sluit één keer aan op gedocumenteerde API’s en events, in plaats van op elk systeem apart.
Workflow
Hoe de workflow verloopt
Bij schone gegevens vraagt het hoofdpad geen handwerk. Wijkt een order, levering of factuur af, dan brengt de uitzonderingslus die bij een mens, met het bewijs en een voorstel, en loopt de goedgekeurde correctie terug door dezelfde integratielaag.
Illustratieve workflow
7 stappen · 1 menselijke controle
Legenda
Systeem
Agent
Persoon
Menselijke controle
Uitzonderingspad
Gekoppelde processen: illustratieve workflow met uitzonderingslus
Lees het diagram als tekst
Het hoofdpad loopt van het één keer vastleggen van een bedrijfsevent in het bronsysteem, via het verspreiden naar de andere systemen met API’s en events en het opbouwen van één tijdlijn per order, naar facturatie, matching en afrekening. Het eindigt bij proceseigenaars die de doorstroming bekijken en de oorzaken van uitzonderingen wegnemen.
Mislukt een stap, loopt hij vertraging op of valt hij buiten de tolerantie, dan verlaat de uitzondering na de tijdlijnstap het hoofdpad. Een agent verzamelt de context en stelt een oplossing voor, en een mens keurt die goed, past ze aan of wijst ze af. De goedgekeurde actie wordt in het bronsysteem uitgevoerd en keert als nieuw event terug naar de verspreidingsstap.
De goedkeuringsstap is het menselijke controlepunt: zonder een mens gebeurt er geen financiële boeking, geen wijziging van een prijs of kredietlimiet en geen verbintenis met een klant.
01
Stap 1: Het event één keer vastleggenSysteem
Een verkooporder uit de webshop, een marktplaats, EDI of van het verkoopteam, een inkooporder of een serviceaanvraag wordt aangemaakt in het systeem dat er eigenaar van is. Dat systeem publiceert een bedrijfsevent in een CloudEvents-envelop, beschreven in een AsyncAPI-contract. Papieren en pdf-orders en leveranciersfacturen gaan eerst door intelligente documentverwerking.
02
Stap 2: Verspreiden via API’s en eventsSysteem
De integratielaag levert het event af bij de magazijn-, transport-, financiële en CRM-systemen, via hun gedocumenteerde API’s (OpenAPI). Afnemende systemen zijn idempotent, zodat een herhaald bericht nooit een tweede zending of factuur aanmaakt, en berichten die niet kunnen worden afgeleverd, wachten in een foutwachtrij tot ze opnieuw worden verwerkt.
03
Stap 3: Eén tijdlijn per order opbouwenSysteem
Statusevents uit elk systeem (bevestigd, gepickt, verzonden, geleverd, gefactureerd, betaald) worden op de zakelijke referentie gecorreleerd tot één tijdlijn. Mijlpaal- en tolerantieregels melden een uitzondering wanneer een stap mislukt, te laat komt of niet klopt: een voorraadtekort, een prijs buiten de afgesproken tolerantie, een mislukte levering, een geweigerde e-factuur.
04
Stap 4: Context verzamelen en voorstellenAgent
Voor elke uitzondering leest een agent wat hij nodig heeft uit de betrokken systemen: de order, de voorraadniveaus, de prijsafspraak, de status bij de vervoerder en de voorwaarden van de klant. Hij stelt een oplossing voor, met zijn redenering en de gegevens die hij gebruikte, zoals een vervangend artikel, een gecorrigeerde prijs, een nieuwe leverdatum of een gecorrigeerde factuur.
Uitzonderingspad: Stap mislukt of buiten tolerantie
05
Stap 5: Goedkeuren binnen drempelsPersoon
Een medewerker van klantenservice, logistiek of financiën ziet de uitzondering, het bewijs en het voorstel op de uitzonderingsdesk, en keurt het voorstel goed, past het aan of wijst het af. De goedgekeurde actie wordt uitgevoerd via de API van het bronsysteem, dat de wijziging als nieuw event publiceert.
Uitzonderingspad: Stap mislukt of buiten tolerantie· Keert terug naar stap 2
Menselijke controle
Agents boeken nooit financiële transacties, wijzigen nooit prijzen of kredietlimieten en gaan geen verbintenis met een klant aan zonder goedkeuring. Drempels per type actie bepalen wie goedkeurt, en elk voorstel en elke beslissing wordt gelogd.
06
Stap 6: Factureren, matchen en afrekenenSysteem
Uitgaande facturen verlaten het ERP als gestructureerde e-facturen (Peppol BIS Billing 3.0, EN 16931) via een toegangspunt. Inkomende leveranciersfacturen worden gematcht met inkooporders en goederenontvangsten, en de betaalstatus van de bank of betaaldienstverlener sluit de tijdlijn af.
07
Stap 7: De doorstroming bekijken en oorzaken wegnemenPersoon
Proceseigenaars en het integratieteam bekijken volgens een vast ritme de uitzonderingen per reden, de fouten in interfaces en de conflicten in stamgegevens. Ze pakken de oorzaak aan waar die zit, in een stamgegevensrecord, een tolerantieregel of een mapping, in plaats van dezelfde uitzondering telkens opnieuw op te lossen.
Componenten
Wat wij zouden bouwen
01
Eventgedreven integratielaag
Contract-first API’s en events tussen ERP, CRM, e-commerce, magazijn, transport en financiën, gespecificeerd in OpenAPI en AsyncAPI met CloudEvents-enveloppen, op uw bestaande integratieplatform of cloud-native gebouwd.
Een afgesproken bronsysteem en eigenaar per gegevensobject, matchingregels voor klanten, leveranciers en producten, en rapporten over duplicaten en conflicten voor de mensen die er eigenaar van zijn.
Een dienst die events correleert tot één tijdlijn per order of aanvraag, mijlpaal- en tolerantieregels toepast, en doorstroming en uitzonderingen zichtbaar maakt voor proceseigenaars.
Een wachtrij met uitzonderingen die de verzamelde context en het voorstel van de agent toont, met acties om goed te keuren, aan te passen of af te wijzen, en met goedkeuringsdrempels per type actie die worden afgedwongen op het punt waar de actie wordt uitgevoerd.
Facturen volgens Peppol BIS Billing 3.0 en EN 16931 in UBL, verzonden en ontvangen via een toegangspunt en gevalideerd vóór verzending, met geweigerde facturen doorgestuurd naar de uitzonderingsdesk.
Monitoring en alerting per interface, runbooks voor het beheerteam en gecontroleerde herverwerking van mislukte berichten, uitgerold met infrastructure as code in uw eigen cloudomgeving.
Inkooporders en orderbevestigingen van leveranciers
Serviceaanvragen en rapporten van de buitendienst
Track-and-trace- en leverevents van vervoerders
Peppol-e-facturen en statusberichten
Bankafschriften en betaalmeldingen
Kern van de oplossing
Gekoppelde processen
Systemen waarmee het werkt
SAP S/4HANA verkoop, inkoop en financiënPlatformSAP
Salesforce Sales, Service en Commerce CloudPlatformSalesforce
Odoo verkoop, voorraad, inkoop en boekhoudingPlatformOdoo
E-commerceplatformen, marktplaatsen en API’s van vervoerders
Magazijn- en transportbeheersystemen
Peppol-toegangspunt, banken en betaaldienstverleners
Productinformatiebeheer en het dataplatform
Controles
Ingebouwde waarborgen
Toegangsgrenzen
Elke integratie en de agent draaien per systeem onder een eigen service-identiteit, beperkt tot de API-operaties die ze nodig hebben. De agent mag over systemen heen lezen om context te verzamelen, maar kan alleen schrijven via een korte lijst van goedgekeurde acties, uitgevoerd via de API van het bronsysteem en nooit via rechtstreekse toegang tot de database.
Menselijke beoordeling
Goedkeuringsdrempels worden per type actie met de proceseigenaar vastgelegd: wat de agent alleen mag voorstellen, wat een teamlid goedkeurt en wat een tweede goedkeurder nodig heeft. Financiële boekingen, wijzigingen van prijzen en kredietlimieten en verbintenissen met klanten wachten altijd op een mens. Acties met weinig impact die terug te draaien zijn, zoals een mislukt bericht opnieuw versturen, kunnen zonder goedkeuring lopen als de eigenaar daarmee instemt.
Controleerbaarheid
Elk event, elk voorstel, elke goedkeuring, afwijzing en uitgevoerde actie wordt gelogd tegen de referentie van de order of aanvraag, met de gegevens die de agent gebruikte, de model- en promptversie en de goedkeurder. Een betwiste factuur of een klacht van een klant is zo stap voor stap te herleiden.
Gegevensbescherming
Contactgegevens van klanten en leveranciers gaan alleen naar de systemen die ze nodig hebben. De tijdlijn bewaart zakelijke referenties en statussen in plaats van volledige records, en logs volgen de bewaartermijn die u vastlegt. De verwerking blijft in de afgesproken regio.
Transparantie over AI
Voorstellen van de agent zijn op de uitzonderingsdesk als zodanig gemarkeerd, met het bewijs en de redenering ernaast. Bronsystemen blijven leidend: de tijdlijn toont wat zij rapporteren en overschrijft ze nooit.
Meetpunten
Wat wij zouden meten
Wij spreken deze meetpunten met u af tijdens de verkenning en halen de nulmeting uit uw huidige systeem- en interfacelogs voordat er iets verandert.
Wat wij zouden meten
Meetpunt
Waarom het telt
Hoe we het zouden meten
01Doorlooptijd van orders
Waarom het teltDe maat die klanten het eerst merken, en die laat zien waar orders blijven liggen.
Hoe we het zouden metenTijd van ontvangst van de order tot levering en tot betaling, per kanaal en entiteit, uit de events van de tijdlijn.
02Orders zonder handmatige tussenkomst
Waarom het teltToont hoeveel van de stroom op schone gegevens en afgesproken regels loopt.
Hoe we het zouden metenAandeel orders en aanvragen dat de afrekening bereikt zonder handmatige stap of uitzondering, uit de tijdlijn.
03Uitzonderingen per reden en oplostijd
Waarom het teltLaat zien welke oorzaken u het eerst moet aanpakken en of de uitzonderingsdesk het werk bijhoudt.
Hoe we het zouden metenAantal uitzonderingen per redencode, en tijd van detectie tot uitgevoerde oplossing, uit de logs van de uitzonderingsdesk.
04Weigeringsgraad van e-facturen
Waarom het teltGeweigerde facturen vertragen de betaling en wijzen meestal op fouten in stamgegevens of mappings.
Hoe we het zouden metenAandeel verzonden en ontvangen e-facturen dat wordt geweigerd, per reden, uit de antwoorden van het toegangspunt.
05Interfacefouten en hersteltijd
Waarom het teltToont of de integratielaag betrouwbaar is en of fouten snel worden opgemerkt en verholpen.
Hoe we het zouden metenMislukte berichten per interface, en tijd van fout tot geslaagde herverwerking, uit de integratiemonitoring.
06Duplicaten en conflicten in stamgegevens
Waarom het teltDe meeste uitzonderingen zijn terug te voeren op gegevens die tussen systemen verschillen.
Hoe we het zouden metenOpenstaande duplicaten en tegenstrijdige waarden per gegevensobject en systeem, uit de matchingrapporten.
Er worden geen doelen vastgelegd zolang er geen nulmeting is.
Uitrol
Hoe wij het zouden uitrollen
Fase 01
Verkenning en proceskaart
Eén proces, zoals order-to-cash voor één verkoopkanaal, en één type uitzondering. Wij brengen de systemen, interfaces en gegevenseigenaars in kaart, en de manier waarop uitzonderingen vandaag worden afgehandeld.
Exitcriteria
Proces, systemen en gegevenseigenaars in kaart gebracht
Eerste type uitzondering en goedkeuringsdrempels afgesproken
Nulmeting uit de huidige logs
Fase 02
Integratie en tijdlijn
Gedocumenteerde API’s en events voor de systemen binnen de scope, en de tijdlijn die naast de bestaande interfaces draait zonder ze te wijzigen.
Exitcriteria
Eventcontracten gepubliceerd en geversioneerd
Tijdlijn komt overeen met de bronsystemen op een steekproef van orders
Herverwerking en runbooks getest
Fase 03
Pilot met de uitzonderingsdesk
Voor het gekozen type uitzondering stelt de agent oplossingen voor, en mensen keuren elk voorstel goed. Wij vergelijken de voorstellen met wat medewerkers zelf zouden hebben gedaan.
Exitcriteria
Kwaliteit van de voorstellen haalt de afgesproken criteria
Drempels en goedkeurders per type actie vastgelegd
Audittrail beoordeeld door financiën en interne controle
Fase 04
Uitbreiden en uitfaseren
Meer types uitzonderingen, kanalen, entiteiten en processen zoals procure-to-pay, telkens op dezelfde contracten. Oude punt-tot-puntkoppelingen worden één voor één uitgeschakeld.
Exitcriteria
Elke nieuwe stroom op dezelfde contracten en monitoring
Orders voor productie op bestelling en voor reserveonderdelen, van het ERP naar het magazijn en de vervoerders, met orderbevestigingen en e-facturen van leveranciers gematcht met inkooporders.
Procure-to-pay met gestructureerde e-facturen van en naar overheden, gematcht met bestellingen en ontvangsten vóór de betaling.
Illustratief voorbeeld
Een groothandel in bouwmaterialen met depots in twee gewesten
Situatie
Een groothandel in bouwmaterialen verkoopt via een webshop, aan de toonbank en via vertegenwoordigers, vanuit depots in Vlaanderen en Wallonië. Orders worden opnieuw ingetypt in het ERP, leveringen op de werf worden telefonisch opgevolgd, en geweigerde Peppol-facturen komen per e-mail terug bij de boekhouding.
Systeem
Orders, voorraad, leveringen en facturen lopen als events tussen webshop, ERP, magazijnsysteem en vervoerders, met één tijdlijn per order. Facturen vertrekken als Peppol BIS Billing 3.0 via één toegangspunt, en inkomende leveranciersfacturen worden gematcht met bestelling en ontvangst.
Menselijke controle
Voorraadtekorten en mislukte leveringen komen op één uitzonderingsdesk, waar een agent een vervangend artikel of een nieuwe leverdatum voorstelt. De binnendienst keurt elk voorstel goed; creditnota’s en prijswijzigingen vragen de goedkeuring van de boekhouding.
Wat we zouden meten
Aandeel orders zonder handmatige tussenkomst per kanaal, uitzonderingen per reden en oplostijd, en het aandeel geweigerde e-facturen.
België
De Peppol-verplichting als event in het proces
Sinds 1 januari 2026 zijn btw-plichtige ondernemingen die in België gevestigd zijn, verplicht om onderling gestructureerde e-facturen uit te wisselen, standaard via Peppol (wet van 6 februari 2024). De tolerantieperiode liep tot 31 maart 2026, en vanaf 1 januari 2028 is e-rapportering gepland, al is die wetgeving nog niet definitief. E-facturen aan overheden lopen via Mercurius.
Wij behandelen de e-factuur als een event in order-to-cash en procure-to-pay: verzonden via een toegangspunt, gematcht met bestelling en ontvangst, en op de uitzonderingsdesk afgehandeld wanneer ze wordt geweigerd. Integraties krijgen gelogde toegang en gedocumenteerde componenten, voor klanten die onder de NIS2-wet vallen.
Nee. Uw ERP, CRM, webshop en magazijnsysteem doen elk hun eigen werk. Wij integreren rond die bronsystemen, spreken af welk systeem eigenaar is van welke gegevens, en geven het proces één tijdlijn over die systemen heen. Waar een oud order- of ERP-systeem verandering tegenhoudt, zet modernisering van legacysystemen het eerst achter API’s.
02Vervangt u onze integratiemiddleware?
Niet als ze haar werk doet. Wij bouwen op het integratieplatform of de message broker die u al gebruikt, en voegen contracten, monitoring en herverwerking toe waar die ontbreken. Is er geen, dan bouwen wij cloud-native. Meer over ons integratiewerk.
03Kunnen agents zelfstandig handelen?
Alleen binnen drempels die u per type actie afspreekt, en alleen voor acties met weinig impact die terug te draaien zijn, zoals een mislukt bericht opnieuw versturen. Financiële boekingen, prijzen, kredietlimieten en verbintenissen met klanten vragen altijd een mens. Lees waar AI-agents menselijke goedkeuring nodig hebben.
04Hoe passen de verplichtingen voor e-facturatie hierin?
Nationale verplichtingen voor e-facturatie gaan op verschillende datums in, en het EU-pakket btw in het digitale tijdperk maakt gestructureerde e-facturatie vanaf 1 juli 2030 de regel voor intracommunautaire B2B-leveringen. Wij behandelen de e-factuur als één event meer in het proces: uitgegeven vanuit het ERP, verzonden via een toegangspunt en afgehandeld op de uitzonderingsdesk wanneer ze wordt geweigerd. Zie onze gids over e-facturatie met Peppol.
05Hoe vermijdt u een nieuw, kwetsbaar web van punt-tot-puntkoppelingen?
Systemen publiceren en consumeren gedocumenteerde events en API’s via één laag, niet via rechtstreekse koppelingen met elkaar. Contracten zijn geversioneerd, afnemende systemen zijn idempotent, mislukte berichten kunnen opnieuw worden verwerkt en elke stroom heeft een benoemde eigenaar. Een nieuw kanaal abonneert zich op bestaande events, in plaats van een koppeling met elk systeem toe te voegen.
06Hoe ziet een eerste scope eruit?
Eén proces en één type uitzondering, bijvoorbeeld order-to-cash voor één verkoopkanaal, met voorraadtekorten als eerste uitzondering. Zo bewijzen de events, de tijdlijn en de goedkeuringsstroom zich voordat er meer bijkomt. Lees meer over onze aanpak.
Bespreek uw order- en factuurstromen
Kies één proces en de systemen waarlangs het loopt. Wij brengen interfaces en uitzonderingen samen met u in kaart en stellen een eerste release voor, met Peppol als vast onderdeel.