Sanntid i treasury og skatt: ERP og bank uten satsvis kjøring

I tjue år levde bedriftsøkonomien med en forsinkelse. ERP-systemet (SAP S/4HANA, Oracle eller Odoo) avsluttet dagens bøker. En planlagt jobb sendte flate CSV- eller MT940-filer til banken over SFTP. Teamet ventet til neste morgen med å få vite hva banken hadde godtatt, og hva som hadde feilet.

Den måten å arbeide på er i ferd med å bryte sammen i GCC, Europa, Midtøsten og Afrika. To endringer har gjort satsvise filer til en direkte forretningsrisiko.

Hvorfor filer over natten sluttet å fungere

• Skatt kontrolleres nå i sanntid. ZATCA fase 2 i Saudi-Arabia, PINT-AE-rammeverket i De forente arabiske emirater og EUs ViDA (VAT in the Digital Age) krever at hver faktura valideres som XML og stemples kryptografisk, i sanntid eller nær sanntid, før den lovlig utstedes eller gjøres opp.

• Betalinger bærer nå rike data. ISO 20022 erstatter korte referansefelt med fullt strukturerte betalingsdetaljer, i betalingsinstrukser (pain.001) og i kontantstyringsmeldinger (camt.053 og camt.054).

Når selskaper legger sanntidsgodkjenning av skatt og ISO 20022 på toppen av gammel satsvis mellomvare, blir resultatet kontanter som holdes tilbake underveis, avstemming som gjøres for hånd, og fakturering som stopper hver gang en kontroll feiler.

Hvorfor standardkoblinger ikke strekker til i produksjon

Standardiserte integrasjonskoblinger håndterer det enkle tilfellet godt. De er ikke bygget for å holde finansielle registreringer konsistente når tusenvis av transaksjoner kommer samtidig. I en etablert virksomhet dukker tre problemer opp igjen og igjen:

• Data som går tapt i oversettelsen. Egendefinerte ERP-tabeller lar seg sjelden mappe rent mot strenge ISO 20022-skjemaer eller UBL 2.1-e-fakturaer uten et nøye, regelbasert mappinglag.

• Duplikater ved nytt forsøk. Når en bank eller en skattegateway får tidsavbrudd under belastning, kan et enkelt nytt forsøk sende samme betaling to ganger eller sende samme faktura to ganger.

• To systemer, to sannheter. ERP-systemet markerer en faktura som postert mens skattemyndigheten avviser stempelet. Finansteamet står igjen med å reversere posteringer for hånd på tvers av systemer som ikke snakker sammen.

Slik bygger vi det

Hos XSIS behandler vi integrasjon som ingeniørarbeid, ikke konfigurasjon. En pålitelig motor for treasury og etterlevelse i sanntid hviler på fire deler.

1. Hver hendelse fanges opp én gang

Vi poller ikke ERP-databasen. Vi fanger opp hver endring idet den skjer, gjennom en transaksjonell utboks eller ERP-systemets eget hendelsesnett. Hver finansiell hendelse får en stabil nøkkel basert på hvor dokumentet kom fra, slik at den behandles nøyaktig én gang på tvers av bank- og skattesystemer.

2. Kontroller før noe forlater systemet

Før en melding når en bank eller en skatteportal, kontrollerer en egen valideringsmotor XML-en mot skjemaet sitt, anvender den kryptografiske signaturen (CSID eller X.509) og lager den påkrevde QR-koden og en hashkjede. Alt dette tar under 50 millisekunder.

3. Ett internt format for hver bank

En versjonert intern datamodell ligger mellom ERP-systemet og omverdenen. Å legge til en ny bank, eller å gå fra MT- til MX-meldinger, betyr ikke å skrive om ABAP- eller PL/SQL-kode i ERP-systemet.

4. Kontoutskrifter avstemt automatisk

Kontoutskrifter (camt.053) og varsler om sanntidsbetalinger (camt.054) leses og avstemmes mot åpne fordringer etter tydelige regler. Mer enn 99 % av postene avstemmes uten manuelle steg, og bare reelle unntak går til en person.

Hvor du bør begynne

Du trenger ikke å erstatte ERP-systemet for å få slutt på forsinkelser fra satsvise kjøringer. Start med Brownfield Diagnostic Bridge: i løpet av 1 til 2 uker kartlegger vi hvor data går tapt mellom ERP-systemet, mellomvaren og bankene dine. Deretter flytter du de mest smertefulle avstemmingsløkkene til sanntid først.