Odoo · Peppol · België
Afgekeurde Peppol-factuur in Odoo: diagnose en behandeling van uitzonderingen
Een operationele gids om een technische afwijzing, een gegevensfout en een zakelijke weigering van elkaar te onderscheiden en deze vervolgens te corrigeren zonder duplicaten te creëren.
Wat betekent « afgewezen » werkelijk?
Het woord « afwijzing » omvat meerdere statussen. Een document kan mislukken voordat het toegangspunt wordt bereikt, worden geweigerd door een formaatregele, technisch aankomen maar niet in de software van de klant terechtkomen, of na ontvangst om commerciële redenen worden betwist. Deze situaties hebben niet hetzelfde bewijs en niet dezelfde correctie. Vraag vóór elke actie welk systeem de status heeft geproduceerd en op welk moment in het traject deze betrekking heeft.
Sinds 1 januari 2026 moeten Belgische btw-plichtige ondernemingen voor de betrokken B2B-transacties gestructureerde elektronische facturen gebruiken. Het federale portaal verduidelijkt dat een PDF die per e-mail wordt verzonden niet volstaat en dat de uitwisseling via Peppol verloopt. Hierdoor wordt het lezen van statussen operationeel: « verzonden » betekent niet automatisch « geleverd » en « geleverd » betekent noch boekhoudkundige validatie, noch akkoord over de prestatie.
Verzamel bewijs voordat u Odoo wijzigt
Begin met het vastleggen van de feiten. Noteer het interne nummer, de elektronische identificatie, de uitgevende onderneming, de ontvanger, het toegangspunt of de dienstverlener, de verzenddatum, de exacte status en het volledige bericht. Exporteer de XML of het beschikbare logboek zonder dit te wijzigen. Een screenshot is nuttig, maar de machinetekst en tijdstempel maken een betrouwbaardere opvolging bij de leverancier of dienstverlener mogelijk.
Vermijd het verwijderen van de factuur, meerdere velden wijzigen en vervolgens opnieuw verzenden. Deze reactie wist de oorzaak en kan een duplicaat creëren als het eerste document uiteindelijk toch is verzonden. Noteer in een organisatie met meerdere bedrijven ook de database, omgeving, log en gebruiker. Teams die werken met webapplicaties en bedrijfstools kunnen de uitzondering zo koppelen aan de juiste bedrijfsgegevens in plaats van elk incident als een generiek Odoo-probleem te behandelen.
Classificeer de uitzondering in zes categorieën
Een goede classificatie verkort de verwerkingstijd. De eerste categorie betreft identificatie: Peppol-deelnemer niet gevonden, btw-nummer, identificatieschema of inconsistent adres. De tweede omvat verplichte velden en referenties. De derde omvat berekeningen, belastingen, afrondingen en eenheden. De vierde betreft een duplicaat of inconsistentie in de cyclus. De vijfde betreft transport, toegangspunt of onbeschikbaarheid. De zesde is een zakelijke weigering: onbekende bestelling, betwiste prijs of niet-erkende prestatie.
De categorie bepaalt de eigenaar. Finance lost zelden een netwerkincident op; IT beslist niet of een creditnota juridisch noodzakelijk is; sales wijzigt geen fiscaal identificatienummer zonder validatie. Voeg daarom categorie, ernst, verantwoordelijke en deadline toe aan het ticket. Een onduidelijke melding kan « nog te kwalificeren » blijven, maar mag zonder bewijs niet automatisch als « Peppol-probleem » worden beschouwd.
Vergelijk statussen, bewijzen en antwoorden
De status moet worden gelezen samen met het bijbehorende bewijs. Een validatieafwijzing vereist een correctie van het document; een transportincident kan een gecontroleerde nieuwe poging vereisen; een zakelijke betwisting vereist een persoon en niet alleen een knop. De onderstaande tabel dient als kader, omdat de exacte labels variëren volgens de Odoo-versie, lokalisatie en dienstverlener.
Beschouw een positieve melding niet als universele goedkeuring. Een technische aanvaarding bevestigt dat een bepaald netwerk- of validatiestadium is doorlopen, terwijl de ontvangende organisatie nog interne controles kan uitvoeren. Omgekeerd bewijst het ontbreken van een update in het scherm niet dat het document verloren is: vergelijk het Odoo-logboek, het portaal van de dienstverlener en indien nodig de ontvangstbevestiging van de ontvanger.
| Type | Bewijs | Aangepaste reactie | Te vermijden |
|---|---|---|---|
| Structurele validatie | Regelcode, veld of pad | Corrigeer de brongegevens en genereer opnieuw | Een totaal forceren of de XML wijzigen |
| Ontvanger niet gevonden | Deelnemer of identificatie niet opgelost | Controleer de entiteit en registratie | Identificaties willekeurig testen |
| Transport geblokkeerd | Logboek van de dienstverlener en tijdstempel | Escaleer en probeer vervolgens gecontroleerd opnieuw | Meerdere nummers aanmaken |
| Mogelijk duplicaat | Reeds geziene identificatie of onduidelijke ontvangstbevestiging | Blokkeer opnieuw verzenden en bevestig de eerste status | Automatisch opnieuw verzenden |
| Zakelijke weigering | Reden van de klant of afwijking van de bestelling | Laat finance/aankoop/sales beslissen | Classificeren als IT-incident |
Structurele validatie
Bewijs: Regelcode, veld of pad
Aangepaste reactie: Corrigeer de brongegevens en genereer opnieuw
Te vermijden: Een totaal forceren of de XML wijzigen
Ontvanger niet gevonden
Bewijs: Deelnemer of identificatie niet opgelost
Aangepaste reactie: Controleer de entiteit en registratie
Te vermijden: Identificaties willekeurig testen
Transport geblokkeerd
Bewijs: Logboek van de dienstverlener en tijdstempel
Aangepaste reactie: Escaleer en probeer vervolgens gecontroleerd opnieuw
Te vermijden: Meerdere nummers aanmaken
Mogelijk duplicaat
Bewijs: Reeds geziene identificatie of onduidelijke ontvangstbevestiging
Aangepaste reactie: Blokkeer opnieuw verzenden en bevestig de eerste status
Te vermijden: Automatisch opnieuw verzenden
Zakelijke weigering
Bewijs: Reden van de klant of afwijking van de bestelling
Aangepaste reactie: Laat finance/aankoop/sales beslissen
Te vermijden: Classificeren als IT-incident
Maak stamgegevens betrouwbaar
De meeste duurzame correcties gebeuren in de stamgegevens, niet in de uiteindelijke XML. Controleer bedrijfsnaam, ondernemings- of btw-nummer, adres, land, deelnemersidentificatie, betalingsgegevens en de waarden die de klant vereist. Bevestig wie deze velden mag wijzigen en volgens welke bron. Een eenmalige correctie op een factuur mag een foutieve partnerfiche niet verbergen die morgen opnieuw tot een afwijzing leidt.
Ga er bij groepen, verenigingen met afzonderlijke activiteiten of organisaties met meerdere vestigingen niet van uit dat één identificatie alle entiteiten dekt. Maak onderscheid tussen juridische entiteit, vestiging, leveringsadres, facturatieadres en contactpersoon. Documenteer het formaat dat wordt gevraagd door klanten die een bestel- of contractreferentie verplicht stellen. Test ten slotte de synchronisatie met CRM, e-commerce of boekhoudkundige import: correcte gegevens in Odoo kunnen door een integratie opnieuw worden overschreven.
Begrijp de validatieregels
Peppol BIS Billing past structurele en rekenkundige regels toe. Een lijn moet onder meer consistent blijven wat betreft hoeveelheid, prijs, korting en nettobedrag; belastingen en totalen moeten volgens de toepasselijke regels met elkaar overeenstemmen. OpenPeppol publiceert deze controles op een verifieerbare manier. De afwijzingsmelding bevat vaak een code en pad die naar de betrokken gegevens verwijzen, ook al blijft deze informatie voor een financiële gebruiker weinig leesbaar.
Corrigeer het totaal niet handmatig om de verzending te forceren. Zoek de oorzaak: ongebruikelijke eenheid, decimale prijs, korting, negatieve hoeveelheid, verkeerde btw-categorie of afronding afkomstig van een connector. Reproduceer de berekening met de brongegevens en bewaar een minimaal voorbeeld. Als het probleem afhankelijk is van de versie of een module, test de correctie dan op een representatieve kopie vóór productie.
Corrigeer en verzend opnieuw zonder duplicaat te creëren
De veilige volgorde omvat vijf beslissingen: bevestig de status van de eerste verzending, kwalificeer de oorzaak, corrigeer de bron, genereer een nieuw document volgens het gekozen proces en controleer vervolgens de ontvangstbevestiging. Als de factuur nooit is afgeleverd en volgens uw procedure nog kan worden gewijzigd, kan correctie en nieuwe uitgifte geschikt zijn. Als de factuur is ontvangen of geboekt, moeten annulering, creditnota of correctiedocument door finance worden beslist.
Vermijd parallelle nummers die uitsluitend worden aangemaakt om « te proberen ». Koppel elke nieuwe verzending aan het incident en het oorspronkelijke document. Noteer in het ticket wie de afwezigheid van een duplicaat heeft bevestigd en welk bewijs de actie afsluit. Schermlabels variëren: het runbook moet verwachte resultaten beschrijven, geen kwetsbare reeks klikken. GVISION raadt ook een vierogencontrole aan voor gevoelige bedragen of correcties van fiscale gegevens.
Behandel ook inkomende uitzonderingen
Ontvangen facturen kunnen technisch geldig zijn maar toch mislukken in het interne proces: leverancier niet herkend, bestelling ontbreekt, kostenplaats onbekend of bedrag wijkt af. Scheid de Peppol-controle van de zakelijke matching. De eerste controleert structuur en verzending; de tweede beslist of de organisatie de uitgave kan registreren, toewijzen en goedkeuren.
Maak een inkomende uitzonderingswachtrij met reden, eigenaar en deadline. Finance beheert boekhoudkundige gegevens, aankoop de bestelling, de aanvrager de prestatie en IT de integratie. Plaats niet alle problematische facturen in een persoonlijke mailbox. Een gedeelde wachtrij of opvolgingstabel voorkomt dat een afwezigheid de betaling blokkeert. De reactie aan de leverancier moet een bruikbare referentie bevatten zonder onnodig persoonsgegevens bloot te stellen.
Automatiseer zonder fouten te verbergen
Nuttige automatisering detecteert, routeert en documenteert; ze zet niet elke fout om in een automatische nieuwe verzending. Activeer een waarschuwing wanneer een status blijft hangen, wanneer dezelfde code zich herhaalt of wanneer het aantal uitzonderingen een vastgestelde drempel overschrijdt. Verrijk het ticket met onderneming, partner, document-ID, waarschijnlijke categorie en link naar het bewijs. Geen enkel geheim of volledige XML mag in een te breed kanaal worden verspreid.
Een aanpak voorautomatisering van bedrijfsprocessen kan Odoo, een ticketingtool en een dashboard synchroniseren. GVISION geeft de voorkeur aan verklaarbare regels: elke automatische actie heeft een voorwaarde, logboek en escalatieroute. Begin met repetitieve gevallen met laag risico en meet vervolgens fout-positieven voordat u gegevenscorrecties of nieuwe verzendingen automatiseert.
Wijs rollen en escalatieniveaus toe
Een robuust proces benoemt vier rollen. De business owner beslist over de realiteit van de transactie. Finance valideert de boekhoudkundige en fiscale verwerking. De applicatiebeheerder controleert configuratie, gegevens en integraties. De dienstverlener of het toegangspunt grijpt in wanneer het bewijs wijst op een transport- of technisch complianceprobleem. Bepaal voor elke foutcategorie wie analyseert, corrigeert, goedkeurt en de klant informeert.
Bepaal ook prioriteiten. Een geïsoleerde factuur zonder onmiddellijke deadline heeft niet dezelfde impact als een blokkering van alle uitgaande facturen aan het einde van een periode. Gebruik volume, waarde, deadline, klant en duplicatierisico. De escalatie bevat een minimaal reproduceerbaar dossier, nooit alleen « Peppol werkt niet ». Dit versnelt externe ondersteuning en voorkomt tegenstrijdige screenshots.
Test vóór en na elke wijziging
Stel een kleine catalogus van scenario’s samen: eenvoudige factuur, meerdere tarieven, korting, creditnota, bestelreferentie, betrokken buitenlandse klant, niet-gevonden partner en grenswaarde voor afronding. De scenario’s moeten uw echte flows weerspiegelen zonder persoonsgegevens uit productie te hergebruiken. Wanneer de leverancier een testomgeving aanbiedt, controleer dan wat deze werkelijk simuleert; een succesvolle test garandeert niet dat de echte ontvanger geregistreerd is.
Herhaal kritieke scenario’s na een update van Odoo, een module of een connector. Vergelijk het geproduceerde document, de statussen en de matching. Bewaar versie, datum en resultaat. Test ook de rechten: een gebruiker moet voldoende informatie kunnen zien om te handelen, zonder fiscale gegevens te kunnen wijzigen of een factuur buiten zijn rol opnieuw te verzenden.
Beheer uitzonderingen met enkele indicatoren
Volg het aantal afwijzingen per honderd documenten, de verdeling per oorzaak, de mediane kwalificatietijd, de oplostijd, het heropeningspercentage en het aantal vermeden of gedetecteerde duplicaten. Deze indicatoren dienen om gegevens en processen te verbeteren, niet om teams te bestraffen. Een algemeen percentage kan verbergen dat één connector, klant of entiteit het grootste deel van de incidenten veroorzaakt.
Analyseer de trends wekelijks bij de start en pas daarna de frequentie aan. Terugkerende fouten moeten leiden tot een actie op de oorzaak: invoerregel, controle vóór verzending, integratiecorrectie of opleiding. Bewaar ook een lijst van statussen zonder duidelijke vervolgstap. Deze voedt de documentatie en aanvragen bij de leverancier. Publiceer geen streeftijd zonder reële supportcapaciteit en zonder onderscheid te maken tussen een technisch incident en een zakelijke beslissing.
Implementeer het runbook in 30 dagen
Breng in de eerste week statussen, beschikbare bewijzen, frequente partners en rollen in kaart. Maak in de tweede week de taxonomie van oorzaken en het ticketmodel. Test in de derde week vijf scenario’s en documenteer correctie, opnieuw verzenden en escalatie. Activeer in de vierde week eenvoudige waarschuwingen, train finance en support en meet de eerste uitzonderingen. Een kort en gebruikt runbook is beter dan een uitgebreide handleiding die nooit wordt geraadpleegd.
Veelvoorkomende fouten zijn bekend: opnieuw verzenden zonder controle, de XML wijzigen in plaats van de bron, levering verwarren met goedkeuring, gevoelige gegevens delen via een openbaar kanaal, afsluiten zonder bewijs of een risicovolle nieuwe verzending automatiseren. Herzie het proces na elk belangrijk incident en bij elke softwarewijziging. Het federale portaal kondigde op 7 april 2026 het einde van de algemene tolerantieperiode aan; uitzonderlijke technische problemen worden individueel beoordeeld, wat het belang van gedateerd bewijs versterkt.
Veelgestelde vragen
Wordt een « verzonden » factuur automatisch ontvangen?
Nee. Controleer de transportstatus en de beschikbare ontvangstbevestiging; een gestarte verzending bewijst niet dat de factuur is afgeleverd.
Kan dezelfde factuur gewoon opnieuw worden verzonden?
Alleen nadat de status van de eerste verzending en het duplicatierisico zijn vastgesteld. De procedure hangt ook af van de reeds uitgevoerde boekhoudkundige verwerking.
Moet de XML rechtstreeks worden gewijzigd?
Nee, niet in een normale productieomgeving. Corrigeer de brongegevens en laat de applicatie een traceerbaar document opnieuw genereren.
Betekent een Peppol-afwijzing dat Odoo defect is?
Nee. De oorzaak kan liggen bij partnergegevens, een validatieregel, een transportincident of een zakelijke vereiste.
Wat moet in het ticket worden bewaard?
Identificaties, tijdstempels, exacte status, code en melding, omgeving, actie, goedkeuring en definitief bewijs.
Wanneer moet een creditnota worden uitgegeven?
De beslissing hangt af van de juridische en boekhoudkundige status van het document. Finance of de boekhouder moet dit valideren.
Kan het opnieuw verzenden worden geautomatiseerd?
Alleen voor nauwkeurig gedefinieerde gevallen met een laag risico, met duplicaatcontrole, logging en escalatie.
Conclusie: maak van afwijzing een beheerst proces
Een goed behandelde afwijzing wordt een verbetering van gegevens, controle of integratie. Het gewenste resultaat is niet alleen een « groene » factuur, maar ook begrijpelijk bewijs, een eigenaar en preventie van herhaling. Om dit runbook om te zetten in Odoo-, ticketing- en verantwoordelijkheidsflows die zijn afgestemd op uw organisatie, kunt u de behandeling van uw uitzonderingen met GVISION afbakenen.