Betalingsfiler og afstemning fra ERP til bank
ERP til bank: betalingsfiler ud, kontoudtog tilbage, afstemt
Betalinger sendt som ISO 20022 pain.001 via host-to-host-SFTP eller bank-API’er, med camt.053- og MT940-kontoudtog afstemt tilbage mod hovedbogen.
Arkitekturskitse
Rul sidelæns for at se hele tegningen.
ERP til bank: betalinger ud, kontoudtog ind
Godkendte betalinger forlader ERP-systemet som signerede ISO 20022-filer over en host-to-host-kanal. Statusrapporter og kontoudtog kommer tilbage samme vej og afstemmes med åbne poster. Afvisninger og uafstemte linjer går til dit team med årsagen vedhæftet.
- Primært flow
- Asynkron
- Undtagelsessti
Forløbet i 10 trin
Forløbet, trin for trin
- Fra ERP til Integrationslag: Godkendt betalingskørsel, over REST/JSON · IDoc (primært flow).
- Fra Integrationslag til Sikker bankkanal: Signeret og krypteret betalingsfil, over ISO 20022 pain.001 · OpenPGP (primært flow).
- Fra Sikker bankkanal til Bank: Leveret til banken, over SFTP H2H (primært flow).
- Fra Bank til Sikker bankkanal: Statusrapporter og kontoudtog, over pain.002 · camt.053 · MT940 (asynkron).
- Fra Sikker bankkanal til Integrationslag: Hentet og valideret, over SFTP H2H (asynkron).
- Fra Integrationslag til Afstemningsmotor: Linjer i kontoudtog, over camt.053 (asynkron).
- Fra Afstemningsmotor til ERP: Afstemte poster bogført, over REST/JSON (primært flow).
- Fra Integrationslag til Treasury- og økonomiteam: Afviste betalinger, med årsagskoden, over pain.002 RJCT (undtagelsessti).
- Fra Afstemningsmotor til Treasury- og økonomiteam: Uafstemte linjer: en afstemningsdifference (undtagelsessti).
- Fra Treasury- og økonomiteam til ERP: Rettet og genindsendt (undtagelsessti).
Oversigt
Dette er flowet mellem et ERP-system og dets banker: godkendte betalinger sendes ud, og statusrapporter og kontoudtog kommer tilbage. Det er den forbindelse, de fleste økonomiteams stadig håndterer manuelt via bankportaler og regneark, og den, hvor en fejl koster penge.
Referencedesignet placerer et integrationslag mellem ERP-systemet og hver bank. Laget oversætter betalinger til bankens variant af ISO 20022 pain.001, signerer og krypterer dem og leverer dem via host-to-host-SFTP, EBICS eller bankens API. Statusrapporter og kontoudtog kommer tilbage samme vej og afstemmes med åbne poster i ERP-systemet.
Fejlstien er designet lige så omhyggeligt som normalforløbet. En afvist betaling kommer tilbage med bankens årsagskode. En kontoudtogslinje, der ikke stemmer, bliver en afstemningsdifference, som en navngiven person skal afklare. Intet forsvinder, og intet bogføres to gange.
Sådan fungerer flowet
Godkend betalingskørslen
Dit ERP-system danner betalingskørslen, og dine godkendere frigiver den, som de gør i dag. Integrationslaget henter kun godkendte kørsler.
Map, signer og krypter
Laget oversætter hver betaling til bankens pain.001-variant, validerer den og signerer og krypterer filen, som banken kræver.
Lever til banken
Filen sendes via den aftalte kanal, host-to-host-SFTP, EBICS eller bankens API, før bankens afskæringstid.
Modtag status og kontoudtog
Banken returnerer pain.002-statusrapporter for hver fil og betaling og camt.053- eller MT940-kontoudtog ved dagens afslutning.
Saml og valider
Laget henter hver rapport, kontrollerer den for huller og dubletter i forhold til kontoudtogenes løbenumre og opdeler den i linjer.
Afstem og bogfør
Kontoudtogslinjer afstemmes med åbne poster efter de regler, du har godkendt, og afstemte posteringer bogføres i ERP-systemet.
Når noget fejler
En betaling afvises
Pain.002-rapporten indeholder bankens årsagskode. Betalingen markeres som afvist i ERP-systemet og sendes til dit treasuryteam, som retter og genindsender den.
En kontoudtogslinje stemmer ikke
Linjen bliver en afstemningsdifference med de sandsynlige kandidater og årsagen til, at den ikke kunne afstemmes. Dit team afklarer den, og reglerne kan lære af den.
En fil mangler eller er forsinket
Kontoudtogenes løbenumre og forventede leveringstider kontrolleres. En manglende eller forsinket fil udløser en alarm, før nogen stoler på likviditetspositionen.
En nøgle eller et certifikat er ved at udløbe
Signeringsnøgler og kanalcertifikater spores med deres udløbsdatoer, og fornyelsen starter tidligt nok til at aftale den nye nøgle med banken.
Standarder og systemer
- Bankstandarder og bankkanaler
- ISO 20022
- pain.001
- pain.002
- camt.052
- camt.053
- camt.054
- MT940
- MT942
- SFTP (H2H)
- EBICS
- Swift
- OpenPGP
Spørgsmål og svar
Host-to-host, EBICS eller bank-API’er: hvilke skal vi bruge?
Det bestemmer banken som regel. Host-to-host-SFTP er den mest udbredte kanal til virksomheders betalingsfiler. EBICS er almindeligt hos banker i Tyskland, Frankrig og nabolandene. Bank-API’er passer til saldi i realtid og øjeblikkelige betalinger, hvor banken tilbyder dem. Mange virksomheder bruger mere end én, og integrationslaget skjuler forskellen for ERP-systemet.
Skal vi modtage camt.053- eller MT940-kontoudtog?
Hvor banken tilbyder begge dele, indeholder camt.053 rigere, strukturerede betalingsoplysninger, hvilket gør automatisk afstemning mere pålidelig. MT940 er stadig udbredt og fungerer godt i mange tilfælde. Vi kan modtage begge, konvertere dem til den samme interne model og flytte hver bank fra MT940 til camt.053, når det passer dig og banken.
Kan vi se vores likviditetsposition i løbet af dagen?
Ja, hvis dine banker leverer intradagsrapporter. De kommer som camt.052- eller MT942-meddelelser eller via et saldo-API. Vi henter dem efter den tidsplan, hver bank understøtter, og viser dem ved siden af kontoudtogene ved dagens afslutning, så dit treasuryteam kan se forventede og faktiske positioner før afskæringstiderne.
Kan vi spore, hvem der har godkendt og sendt en betaling?
Ja. Godkendelsen forbliver i dit ERP-system med de eksisterende kontroller. Integrationslaget logger hver fil, det opretter, signerer, sender og modtager, med tidsstempler, identifikatorer og den tekniske konto, der blev brugt. Loggen forbinder hver betaling i bankens statusrapport med ERP-bilaget og dets godkendere.
Vi har flere banker. Er hver bank et separat projekt?
Nej. Integrationslaget, den interne betalingsmodel og afstemningsreglerne bygges én gang. Hver ny bank tilføjer sin egen formatvariant, kanal og sine egne onboardingtrin, som er mindre arbejdsopgaver. Vi forbinder som regel den bank med størst volumen først og tilføjer de andre efter tur.
Hvordan testes forbindelsen før idriftsættelsen?
Hver bank stiller et testmiljø eller en testproces til rådighed. Vi aftaler en række testcases med banken, der dækker hver betalingstype, afvisninger og kontoudtog, kører dem og gemmer dokumentationen. Når banken godkender, går vi i drift med en lille første betalingskørsel og sammenligner resultaterne, før vi flytter resten.
Start med en samtale, ikke en kontrakt.
Fortæl os, hvad du skal bygge, forbinde eller sikre. En arkitekt gennemgår det med dig og anbefaler derefter, hvor du skal starte.
Det sker der nu
Aftale om tidspunkt
Vores team sender dig en e-mail for at aftale et tidspunkt for sessionen.
Forhåndskonsultation
En gratis online forhåndskonsultation på 30 minutter: vi gennemgår dine mål, systemer og begrænsninger.
Parathedsanalyse
I en gratis parathedsanalyse på 48 timer tjekker en ledende arkitekt dit projekt op mod de 6 punkter i Definition of Ready og anbefaler det spor, der passer.
Valg af spor
Projekter med et klart omfang modtager et bindende forslag inden for 3 til 5 hverdage. Projekter i konceptfasen starter i Blueprint Studio. Et system i drift, der fejler, er udokumenteret eller skal integreres, starter med en diagnosticering på 1 til 2 uger. Blueprint Studio og diagnosticeringen har hver et fast honorar, som er angivet i forslaget.