Voorbij batchbestanden: realtime treasury en belasting

Twintig jaar lang leefde de financiële functie van bedrijven met vertraging. Het ERP (SAP S/4HANA, Oracle of Odoo) sloot de boeken van de dag. Een geplande taak stuurde platte CSV- of MT940-bestanden via SFTP naar de bank. Het team wachtte tot de volgende ochtend om te horen wat de bank had geaccepteerd en wat was mislukt.

Die manier van werken brokkelt af in de GCC, Europa, het Midden-Oosten en Afrika. Twee veranderingen hebben batchbestanden tot een direct bedrijfsrisico gemaakt.

Waarom nachtelijke bestanden niet meer werken

• Belasting wordt nu in realtime gecontroleerd. De ZATCA-fase 2 van Saudi-Arabië, het PINT-AE-kader van de VAE en de btw in het digitale tijdperk (ViDA) van de EU eisen dat elke factuur als XML wordt gevalideerd en cryptografisch wordt gestempeld, in realtime of bijna realtime, voordat zij wettelijk wordt uitgereikt of afgewikkeld.

• Betalingen dragen nu rijke data. ISO 20022 vervangt korte referentievelden door volledig gestructureerde betalingsgegevens, in betaalopdrachten (pain.001) en in berichten voor cashmanagement (camt.053 en camt.054).

Wanneer bedrijven realtime fiscale vrijgave en ISO 20022 boven op oude batchmiddleware zetten, is het resultaat: geld dat onderweg vastzit, afstemming die met de hand gebeurt en facturering die stopt zodra een controle mislukt.

Waarom standaardconnectoren in productie tekortschieten

Standaardconnectoren voor integratie doen het eenvoudige geval goed. Ze zijn niet gebouwd om financiële gegevens consistent te houden wanneer duizenden transacties tegelijk binnenkomen. In een gevestigde onderneming komen drie problemen steeds weer terug:

• Data gaat verloren in de vertaling. Eigen ERP-tabellen passen zelden schoon op strikte ISO 20022-schema’s of UBL 2.1-e-facturen zonder een zorgvuldige, op regels gebaseerde mappinglaag.

• Duplicaten bij opnieuw proberen. Wanneer een bank of een fiscale gateway onder belasting een time-out krijgt, kan een eenvoudige nieuwe poging dezelfde betaling twee keer versturen of dezelfde factuur twee keer indienen.

• Twee systemen, twee waarheden. Het ERP markeert een factuur als geboekt, terwijl de belastingdienst haar stempel afwijst. Het financiële team moet boekingen met de hand terugdraaien in systemen die niet met elkaar praten.

Hoe wij het bouwen

Bij XSIS behandelen we integratie als engineering, niet als configuratie. Een betrouwbare realtimemotor voor treasury en compliance rust op vier delen.

1. Elke gebeurtenis eenmalig vastleggen

Wij bevragen de ERP-database niet periodiek. Wij leggen elke wijziging vast op het moment dat zij gebeurt, via een transactionele outbox of het eigen eventnet van het ERP. Elke financiële gebeurtenis krijgt een stabiele sleutel op basis van de herkomst van het document, zodat zij precies een keer wordt verwerkt in de bank- en fiscale systemen.

2. Controles voordat er iets uitgaat

Voordat een bericht een bank of een fiscaal portaal bereikt, controleert een aparte validatiemotor de XML tegen het schema, zet de cryptografische handtekening (CSID of X.509) en maakt de vereiste QR-code en hashketen. Dat alles duurt minder dan 50 milliseconden.

3. Een intern formaat voor elke bank

Een intern datamodel met versiebeheer staat tussen het ERP en de buitenwereld. Een nieuwe bank toevoegen, of overstappen van MT- naar MX-berichten, betekent niet dat u ABAP- of PL/SQL-code in het ERP hoeft te herschrijven.

4. Bankafschriften automatisch afgestemd

Bankafschriften (camt.053) en meldingen van instantbetalingen (camt.054) worden gelezen en volgens duidelijke regels afgestemd tegen openstaande vorderingen. Meer dan 99% van de posten wordt zonder handmatige stap afgestemd, en alleen echte uitzonderingen gaan naar een persoon.

Waar u begint

U hoeft uw ERP niet te vervangen om batchvertragingen te beëindigen. Begin met onze Brownfield Diagnostic Bridge: in 1 tot 2 weken brengen we in kaart waar data verloren gaat tussen uw ERP, uw middleware en uw banken. Daarna verplaatst u de pijnlijkste afstemmingslussen eerst naar realtime.