Uitgaande factuur vrijgeven: van order en levering naar controleerbaar bewijs

Je hebt een order die volgens sales klaar is, maar de levering staat in het magazijn nog op ‘deels geleverd’. Een factuur die toch vertrekt, is geen automatisering maar een voorschot op een discussie met je klant.

De veilige route loopt van order en leverbewijs naar een controleerbaar factuurvoorstel, daarna pas naar menselijke vrijgave, verzending en read-back. Zo weet je dát er een factuur is verstuurd én welke bron, versie en beslissing dat rechtvaardigen.

Wat je nodig hebt voor factuurvrijgave

Controleerbaar factuurbewijs is een samenhangend dossier waarin order, geleverde prestatie, klantgegevens, factuurregels, btw, vrijgavebesluit en uiteindelijke verzending naar elkaar verwijzen. Het dossier bewaart de oorspronkelijke bronnen, de gebruikte versies en de afwijkingen. Daardoor kan iemand anders later reconstrueren waarom deze factuur wel vertrok en een vergelijkbare factuur niet.

Begin met de grens tussen de bronnen. Een order bewijst wat is afgesproken. Een verzend- of opleverrecord bewijst wat is geleverd. Een klantakkoord kan een ontbrekend fysiek leverbewijs aanvullen, maar niet stilzwijgend vervangen. De factuur is de financiële vertaling van die feiten, niet de bron ervan.

Voor goederen heb je minimaal een order-ID, orderregels, de afgesproken prijs, aantallen, btw-behandeling, leverstatus en een leverbewijs nodig. Dat leverbewijs kan een WMS-status zijn met een zendings-ID, een ondertekende afleverregistratie of een aantoonbaar klantakkoord. Voor diensten vervang je de zending door een goedgekeurd urenoverzicht, opleverdocument of acceptatie in het klantportaal.

De Nederlandse factuurbaseline is concreet. De Belastingdienst noemt onder meer volledige namen en adressen, btw-identificatienummer, KVK-nummer, uitreikdatum, een uniek opeenvolgend factuurnummer, geleverde goederen of diensten, leverdatum en bedragen exclusief btw, geraadpleegd op 23 oktober 2026. Laat deze velden als controles in je workflow staan. Een boekhoudpakket dat een document kan maken, controleert niet automatisch of de order de juiste zakelijke aanleiding vormt.

Maak voor ieder factuurvoorstel een bronkaart. Dit is het minimum dat ik zou vastleggen:

Bewaar ook een bronversie of snapshot-ID. Alleen updated_at is kwetsbaar: twee wijzigingen kunnen dezelfde seconde delen en een late verwerking kan alsnog op een oude lezing werken. De koppeling tussen bronversie, idempotentiesleutel en read-back komt ook terug in de aanpak voor data-sync met bronversies en veilige vrijgave.

Je hebt verder vier rollen nodig:

• Procesverantwoordelijke: bepaalt wanneer order en levering voldoende bewijs vormen.
• Finance-eigenaar: beheert grootboek, btw-regels, factuurnummering en creditnota’s.
• Technisch eigenaar: beheert API-rechten, retries, logging en herstel.
• Vrijgever: mag een uitzondering accepteren binnen een benoemd mandaat.

Zonder aangewezen vrijgever wordt een uitzonderingsqueue een wachtkamer. Zonder finance-eigenaar verschuift een prijs- of btw-beslissing naar code. Dat is precies de verkeerde plek.

Zet vóór de bouw één proefset klaar met een volledige levering, een deellevering, een geannuleerde regel, een gewijzigde prijs, een dubbele ordermelding en een timeout na het schrijven. Test met echte veldvormen uit je eigen systemen, maar gebruik geen echte klantfacturen in de eerste ontwikkelronde.

Concrete stappen: van order naar vrijgegeven factuur

1. Definieer de statussen die je werkelijk wilt bewijzen

Gebruik geen enkel veld ready=true. Maak de beslissingen los van elkaar. Een praktische statusketen is:

1. order_accepted: de order is commercieel bevestigd.
2. delivery_proved: de relevante goederen of diensten zijn aantoonbaar geleverd.
3. matched: regels, aantallen, prijzen, btw en klantgegevens sluiten aan.
4. draft_created: het boekhoudpakket heeft een concept of voorstel opgeslagen.
5. human_released: een bevoegde persoon heeft het concept vrijgegeven.
6. sent: de verzending is aangevraagd.
7. verified: het doelrecord en de relevante bronwaarden zijn teruggelezen en komen overeen.

Een uitzondering krijgt een eigen status, zoals missing_delivery, partial_delivery, price_mismatch, duplicate_candidate, customer_data_missing of write_unconfirmed. Zo ziet een medewerker meteen welke beslissing nog nodig is.

2. Maak één bronkaart per order en levering

Lees bij een trigger niet alleen de order-ID uit het event. Haal de actuele order, de actuele leverregels en de klantreferentie opnieuw op. Leg van elk record vast welke bron, versie en peiltijd bij de lezing horen.

Voor een goederenorder staat op de kaart minstens:

Een ordernummer in een e-mail is geen leverbewijs. Een status shipped is niet automatisch delivered. Een scan in het magazijn bewijst dat een pakket is verwerkt, niet dat een contractueel afgesproken installatie is opgeleverd. Kies dus vooraf welke status voor jouw bedrijf voldoende is.

Bij een serviceorder kan de bewijsregel luiden: urenstaat approved én oplevering accepted. Bij een abonnement kan het een contractperiode en actieve dienststatus zijn. Zet die keuze in beleid, niet in een ongedocumenteerde uitzondering in de code.

3. Match op regelniveau, niet op het ordernummer

Match iedere factuurregel met de orderregel en het leverbewijs. Controleer minimaal SKU of dienstcode, geleverde hoeveelheid, afgesproken eenheidsprijs, korting, btw-code, leverdatum en valuta. Vergelijk bedragen in de kleinste eenheid die je systeem betrouwbaar ondersteunt en rond pas op de afgesproken factuurgrens af.

Maak de berekening zichtbaar. Stel dat een regel 12 stuks bevat en het leverbewijs 10 stuks meldt. Dan zijn er drie mogelijke uitkomsten: je factureert 10 als deelbetaling volgens contract, je wacht op de resterende 2, of je vraagt een bevoegde eigenaar om een bewuste afwijking. De workflow mag die keuze niet verstoppen achter een groen ordernummer.

Voor elektronische facturen heeft Peppol BIS Billing 3.0 een nuttige scheiding. De actuele specificatie vereist een buyer reference of purchase order reference; een verkooporderreferentie kan apart worden meegestuurd. De Peppol-regel voor OrderReference maakt dus ruimte voor zowel de inkoopreferentie van de klant als jouw verkooporderreferentie, gecontroleerd op 23 oktober 2026. Zo kan de ontvanger de factuur terugbrengen naar zijn orderproces, zonder dat die referentie jouw leverbewijs vervangt.

Peppol kan ook leverinformatie dragen. De UBL-structuur bevat onder meer werkelijke leverdatum en afleverlocatie, maar die velden zijn een weergave in de factuur. De bronkaart moet nog steeds verwijzen naar het onderliggende bewijsstuk en de bronversie.

4. Routeer uitzonderingen naar een eigenaar

Laat een afwijking niet eindigen in een algemene foutmelding. Maak van ieder queue-item een kleine werkopdracht met reden, eigenaar, deadline, bewijslinks en toegestane beslissingen.

De queue maakt menselijke controle kleiner, niet groter. De medewerker hoeft bij een volledige match niet ieder veld opnieuw over te typen. Die persoon beslist alleen over het ontbrekende bewijs of de afwijking die buiten de automatische regel valt.

5. Maak eerst een concept in het boekhoudpakket

Schrijf pas naar het boekhoudpakket nadat de bronkaart en matching klaar zijn. Gebruik een concept als veilige tussenlaag. Geef het concept een externe referentie naar de order, de leveringsbatch, de bronversie en jouw billing-ledgerrecord.

Moneybird beschrijft voor de API precies dit patroon: je hebt een toegangstoken, administratie-ID, contact, grootboekrekening en btw-tarief nodig voordat je een sales invoice maakt. De actuele Moneybird-stappen maken van de contactzoekactie en de keuze van ledger_account_id en tax_rate_id expliciete vereisten, laatst gewijzigd op 22 oktober 2026 en geraadpleegd op 23 oktober 2026.

Leg in je eigen opdrachtrecord vast:

business_key: SO-2026-1048
delivery_key: DEL-2026-884
source_version: order-v7 + delivery-v3
proposal_hash: sha256:...
idempotency_key: invoice:SO-2026-1048:DEL-2026-884:v1
target_state_required: draft

Een workflowtool zoals n8n of Make mag de stappen orkestreren. Laat de workflowtool niet de enige opslagplaats voor bewijs zijn. Bewaar de bronkaart, hash, request, response en beslissing in een eigen tabel of documentopslag die je kunt exporteren.

6. Laat een bevoegde persoon vrijgeven

Toon de vrijgever één scherm met vier kolommen: order, levering, voorstel en afwijkingen. Maak iedere waarde klikbaar naar de bron. Geef geen knop goedkeuren wanneer het systeem niet laat zien wat er wordt goedgekeurd.

Een vrijgavebesluit bevat minstens:

• de beslissing release, hold of reject;
• de naam of stabiele gebruikers-ID van de vrijgever;
• tijdstip en mandaatniveau;
• bronversie en voorstelhash;
• eventuele reden voor een geaccepteerde afwijking;
• de volgende actie, bijvoorbeeld concept versturen of bewijs aanvullen.

De gebruiker hoeft geen modelscore te beoordelen. Die score kan helpen om een record te rangschikken, maar een hoge herkenningsscore bewijst niet dat de levering compleet is. Dezelfde grens geldt voor documenten: OCR kan factuurvelden lezen, maar bewijs, eigenaar en read-back bepalen pas of de financiële beslissing controleerbaar is.

7. Verstuur, lees terug en sluit de poging af

Verzenden is een aparte schrijfactie. Gebruik dezelfde billing-ledgerrecord en idempotentiesleutel. Bij een timeout zoek je eerst op die sleutel of externe referentie naar een bestaand doelrecord. Je maakt niet blind een tweede factuur.

Moneybird maakt het onderscheid zichtbaar in de API. Een concept heeft nog geen invoice_id; na de send-aanroep gaat de status van draft naar open. De API beschrijft ook reference, factuurdatum, vervaldatum, factuurregels, totaalvelden en verzenddatum als terugleesbare gegevens, geraadpleegd op 23 oktober 2026. Dat geeft je een concreet read-back-contract.

Lees na het versturen minstens terug:

1. doel-ID en factuurnummer;
2. klant-ID, juridische naam en referentie;
3. alle regels, hoeveelheden, prijzen, btw-codes en grootboekrekeningen;
4. netto-, btw- en brutototaal;
5. factuurdatum, leverdatum en vervaldatum;
6. verzendstatus, sent_at en gekozen bezorgmethode;
7. de opgeslagen UBL of PDF, als die als bewijs moet worden bewaard.

Markeer verified alleen wanneer de teruggelezen waarden overeenkomen met de vrijgegeven payload en de bronversies nog geldig zijn. Ontstaat de read_back_mismatch vóór verzending, blokkeer dan de verzendactie en routeer de oorzaak naar de benoemde finance-eigenaar. Is de factuur al verzonden, stop dan retries, bewaar het doelrecord en routeer een correctie of creditnota naar diezelfde finance-eigenaar. Een HTTP 200 is een technisch antwoord, geen financieel bewijs.

Bewaar de factuur in de vorm waarin je haar hebt verstuurd, samen met order-, lever- en beslisbewijs. De Belastingdienst verlangt dat verstuurde en ontvangen facturen in de oorspronkelijke vorm worden bewaard, normaal 7 jaar, gecontroleerd op 23 oktober 2026. Laat je opslag dus niet alleen een actuele API-weergave bewaren die later kan veranderen.

Valkuilen die je factuurstroom breken

Een order wordt als levering gelezen

Een geaccepteerde order is een afspraak. Factureren op die order kan commercieel correct zijn bij vooruitbetaling, maar dat moet een bewuste factuurregel zijn. Voor levering-na-ontvangst is een orderstatus onvoldoende. Leg het toegestane factuurmoment per producttype of contract vast.

Eén match op ordernummer maakt alles groen

Een order kan drie deelleveringen, twee prijzen en één retour bevatten. Match daarom per regel en bewaar ook de aantallen die niet zijn gefactureerd. Een totaalsom kan toevallig kloppen terwijl de verkeerde regel is geleverd. Het verschil tussen omzet, betaling en bronbewijs zie je ook bij een gekoppelde kassa met afzonderlijke dagstaat, betaalactie en boeking.

Deellevering wordt stilzwijgend volledig gefactureerd

Maak partial_delivery zichtbaar. De workflow kiest niet zelf tussen deelfacturatie, wachten en contractafwijking. Een commerciële eigenaar doet dat met de bijbehorende order- en klantafspraak.

Een creditnota wist de oude fout

Een al verstuurde factuur pas je niet terug in het bewijsdossier. Maak een creditnota of correctie met verwijzing naar de oorspronkelijke factuur, reden, eigenaar en nieuwe onderliggende levering. Zo blijft zichtbaar wat er eerst is verstuurd.

Een retry maakt een tweede factuur

Een netwerkfout kan optreden nadat het boekhoudpakket de factuur heeft opgeslagen. Zoek vóór een nieuwe poging op billing-ledgerrecord, externe referentie en doel-ID. Gebruik een vaste idempotentiesleutel en leg een onzekere write vast als aparte status.

Stamdata wordt pas na verzending gecontroleerd

Een verkeerde juridische naam, btw-code of Peppol-identificatie is geen cosmetisch probleem. Valideer klant en afleverrelatie voordat je het concept vrijgeeft. Bij Peppol vereist de Moneybird-flow dat je administratie geregistreerd is en dat het contact een geldige identifier heeft; voor een Nederlandse KVK gebruikt de actuele documentatie code 0106 plus het KVK-nummer. De Moneybird Peppol-stappen zetten die vereisten vóór het maken en verzenden van de factuur, geraadpleegd op 23 oktober 2026.

Concept en verzending zijn één knop

Een concept geeft je een controlepunt. Als een workflow het concept meteen verstuurt, bestaat de menselijke vrijgave alleen op papier. Scheid de API-rechten voor aanmaken en verzenden waar het pakket dat toelaat, en meet beide gebeurtenissen apart.

Read-back kijkt alleen naar de status

open of sent zegt niet of het totaal, de btw of de klantrelatie klopt. Vergelijk de velden die de beslissing dragen. Bij een mismatch vóór verzending blokkeer je de verzendactie; na verzending stop je retries, bewaar je het doelrecord en routeer je een correctie of creditnota naar de benoemde finance-eigenaar.

De queue heeft geen eigenaar

Een foutmelding zonder persoon en deadline blijft liggen tot de maandafsluiting. Geef ieder item een reden, eigenaar, vervaldatum, bewijslink en toegestane beslissingen. Meet ook de leeftijd van openstaande uitzonderingen. Een automatisering die alleen sneller queue-items maakt, heeft het proces niet verbeterd.

Beslis-kader: standaardpakket, workflow of maatwerk?

Kies de kleinste aanpak die jouw zwaarste fout afvangt. Een native flow in je boekhoudpakket past bij één orderbron, één duidelijke leverstatus, weinig variatie en een medewerker die concepten kan controleren. Een workflowlaag past wanneer order, WMS, klantportaal en boekhouding gegevens moeten combineren en je een herhaalbare queue wilt. Maatwerk is pas logisch wanneer deel- en deelleveringen, meerdere entiteiten, contractafwijkingen of hoge foutkosten een eigen bewijsmodel rechtvaardigen.

Begin niet met factuurvolume. Kijk eerst naar variatie en foutschade:

• Standaardpakket: kies dit als de order en levering al in hetzelfde pakket leven, de regels eenvoudig zijn en een handmatige check per uitzondering haalbaar blijft.
• Workflowlaag: kies dit als je bronnen wilt koppelen, bronkaarten wilt bewaren en een vaste beslisqueue nodig hebt. n8n is een concreet voorbeeld: de actuele Cloud-prijzen rekenen per workflowuitvoering en niet per stap. De Starter kost €20 per maand bij jaarlijkse facturatie voor 2.500 uitvoeringen; Pro kost €50 voor 10.000 uitvoeringen. Deze bedragen zijn gecontroleerd op 23 oktober 2026. De workflowlaag vervangt je bewijsopslag niet.
• Maatwerk: kies dit als je een eigen billing-ledger, bronversies, autorisatiematrix, herstelpad en read-back over meerdere systemen nodig hebt. Je koopt dan geen losse connector, maar een beheerd proces.

Automatiseer nog niet als je geen betrouwbare leverstatus hebt, niemand een uitzondering mag vrijgeven of de contractregel over het factuurmoment niet duidelijk is. Eerst het beleid en de bronkaart. Daarna de techniek.

Uitgewerkt voorbeeld: een order veilig naar Moneybird

Dit is een fictief testschema om de beslissingen zichtbaar te maken, geen klantcase. Stel dat een installatiebedrijf een order SO-2026-1048 heeft met twee goederenregels en transport:

De orderbron levert order-v7. Het WMS levert DEL-2026-884 met delivery-v3, status delivered, leverdatum 22 oktober 2026 en bewijsstuk pod-7781. De workflow maakt de idempotentiesleutel invoice:SO-2026-1048:DEL-2026-884:v1.

Stap voor stap:

1. De workflow zoekt de klant op met de vaste klant-ID, niet op alleen bedrijfsnaam. Juridische naam, adres en btw-id komen overeen met de order.
2. De regelmatch vindt 10 van 10 montagekits, 4 van 4 gateways en 1 transportregel. De prijs komt uit de geaccepteerde orderversie, niet uit de actuele catalogus.
3. Finance heeft voor deze regels 21% btw en de juiste omzetrekeningen vastgelegd. Het voorstel wordt €2.625,00 excl. btw, €551,25 btw en €3.176,25 incl. btw.
4. De workflow slaat de bronkaart en payloadhash op. Er bestaat nog geen ledgerrecord voor deze sleutel, dus er is geen duplicate candidate.
5. Moneybird krijgt een concept met contact-ID, referentie SO-2026-1048, factuurdatum 23 oktober 2026, vervaldatum volgens de klantafspraak en de drie regels. Het concept blijft draft.
6. De vrijgever ziet order, leverbewijs, bedragen en bronversies naast elkaar. Die persoon kiest release en het systeem slaat decision-2026-1048 op.
7. De verzendactie gaat naar de gekozen bezorgmethode. Voor e-mail controleert de workflow het afleveradres. Voor Peppol controleert hij vooraf registratie van de administratie en de klantidentifier.
8. De workflow leest Moneybird terug. Hij bewaart het doel-ID, factuurnummer, status open, sent_at, referentie, detailregels en totalen. De vergelijking met het voorstel slaagt, dus het dossier wordt verified.

Wat gebeurt er als het WMS 2 gateways minder meldt? Dan is het voorstel geen €3.176,25 meer. De workflow zet partial_delivery in de queue met drie toegestane uitkomsten: factureren van de geleverde twee gateways en de overige regels, wachten op de resterende levering, of een contractafwijking laten vrijgeven. De factuur vertrekt niet omdat een medewerker toevallig het ordernummer herkent.

Wat gebeurt er na een timeout op de verzendactie? De workflow zoekt eerst op de ledger-sleutel en het Moneybird-doel-ID. Vindt hij een concept of open factuur, dan hergebruikt hij dat record. Vindt hij niets en blijft de status onduidelijk, dan krijgt het item write_unconfirmed en beslist een eigenaar. Een tweede POST zonder die controle kan een tweede factuur maken.

Vergelijkingstabel: welke aanpak past bij jouw situatie?

De bedragen hieronder zijn publieke prijsinformatie die ik op 23 oktober 2026 heb gecontroleerd. Ze zijn licentieprijzen, geen totaalprijs voor inrichting, koppeling, testen, beheer of fiscale inrichting.

Moneybird publiceert voor zijn huidige pakketten de limieten voor gebruikers, banktransacties en bankkoppelingen; vanaf Start zijn verkoopfacturen niet meer per maand gelimiteerd. De actuele pakketpagina noemt ook dat facturen versturen en Peppol geen aparte pakketfunctieprijs hebben, bijgewerkt op 22 oktober 2026 en geraadpleegd op 23 oktober 2026. De licentie is dus niet hetzelfde als een veilige order-naar-factuurflow.

De praktische keuze is eenvoudig te maken. Heb je één bron en weinig uitzonderingen, begin met een conceptstatus en menselijke vrijgave in het pakket dat je al gebruikt. Heb je meerdere bronnen, bouw dan eerst de bronkaart en queue voordat je een connector kiest. Heb je contractafhankelijke regels of hoge herstelkosten, maak de ledger en het read-back-contract leidend en laat de toolkeuze daarop volgen.

Een factuur hoort pas te vertrekken wanneer je kunt aanwijzen wat de klant heeft besteld, wat werkelijk is geleverd, welke regels en bedragen zijn gecontroleerd, wie de uitzondering of vrijgave droeg en wat het boekhoudpakket uiteindelijk heeft opgeslagen. Dat is geen rem op automatisering. Het is de grens die ervoor zorgt dat sneller factureren niet eindigt in trager herstellen.