Betalingsfiler og avstemming mellom ERP og bank
ERP til bank: betalingsfiler ut, kontoutskrifter tilbake, avstemt
Betalinger sendes som ISO 20022 pain.001 over host-to-host SFTP eller bank-API-er, og camt.053- og MT940-kontoutskrifter avstemmes mot hovedboken.
Blueprint
Rull sidelengs for å se hele tegningen.
ERP til bank: betalinger ut, kontoutskrifter inn
Godkjente betalinger forlater ERP-systemet som signerte ISO 20022-filer over en host-to-host-kanal. Statusrapporter og kontoutskrifter kommer tilbake samme vei og matches mot åpne poster. Avvisninger og linjer uten match går til teamet ditt med årsaken vedlagt.
- Hovedforløp
- Asynkron
- Unntaksbane
Forløpet i 10 steg
Forløpet, steg for steg
- Fra ERP til Integreringslag: Godkjent betalingskjøring, over REST/JSON · IDoc (hovedforløp).
- Fra Integreringslag til Sikker bankkanal: Signert og kryptert betalingsfil, over ISO 20022 pain.001 · OpenPGP (hovedforløp).
- Fra Sikker bankkanal til Bank: Levert til banken, over SFTP H2H (hovedforløp).
- Fra Bank til Sikker bankkanal: Statusrapporter og kontoutskrifter, over pain.002 · camt.053 · MT940 (asynkron).
- Fra Sikker bankkanal til Integreringslag: Samlet inn og validert, over SFTP H2H (asynkron).
- Fra Integreringslag til Avstemmingsmotor: Kontoutskriftslinjer, over camt.053 (asynkron).
- Fra Avstemmingsmotor til ERP: Avstemte poster postert, over REST/JSON (hovedforløp).
- Fra Integreringslag til Treasury- og finans teamet: Avviste betalinger, med årsakskode, over pain.002 RJCT (unntaksbane).
- Fra Avstemmingsmotor til Treasury- og finans teamet: Uavstemte linjer: et avstemmingsavvik (unntaksbane).
- Fra Treasury- og finans teamet til ERP: Korrigert og sendt på nytt (unntaksbane).
Oversikt
Dette er flyten mellom en ERP og bankene: godkjente betalinger går ut, og statusrapporter og kontoutskrifter kommer tilbake. Det er tilkoblingen de fleste finansavdelinger fortsatt gjør manuelt, via bankportaler og regneark, og den der en feil koster penger.
Referansedesignet legger et integreringslag mellom ERP-en og hver bank. Laget mapper betalinger til bankens variant av ISO 20022 pain.001, signerer og krypterer dem og leverer dem over host-to-host SFTP, EBICS eller bankens API. Statusrapporter og kontoutskrifter kommer tilbake samme vei og avstemmes mot åpne poster i ERP-en.
Feilbanen er designet like nøye som normalforløpet. En avvist betaling kommer tilbake med bankens årsakskode. En kontoutskriftslinje som ikke samsvarer, blir et avstemmingsavvik som en navngitt person må rydde opp i. Ingenting forsvinner, og ingenting posteres to ganger.
Slik fungerer flyten
Godkjenn betalingskjøringen
ERP-en din lager betalingskjøringen, og godkjennerne dine frigir den, som i dag. Integreringslaget henter bare godkjente kjøringer.
Map, signer og krypter
Laget mapper hver betaling til bankens pain.001-variant, validerer den og signerer og krypterer filen slik banken krever.
Lever til banken
Filen sendes over avtalt kanal, host-to-host SFTP, EBICS eller bankens API, før bankens innleveringsfrist.
Motta status og kontoutskrifter
Banken returnerer pain.002-statusrapporter for hver fil og betaling, og camt.053- eller MT940-kontoutskrifter ved dagens slutt.
Samle inn og valider
Laget samler inn hver rapport, kontrollerer den for hull og duplikater mot kontoutskriftssekvensen og tolker den om til linjer.
Avstem og poster
Kontoutskriftslinjer avstemmes mot åpne poster med reglene du godkjente, og avstemte poster posteres i ERP-en.
Når noe feiler
En betaling avvises
pain.002-rapporten inneholder bankens årsakskode. Betalingen merkes som avvist i ERP-en og sendes til treasury-teamet ditt for retting og ny innsending.
En kontoutskriftslinje samsvarer ikke
Linjen blir et avstemmingsavvik med de sannsynlige kandidatene og årsaken til at den ikke samsvarte. Teamet ditt rydder opp, og reglene kan lære av det.
En fil mangler eller er forsinket
Sekvensnumre for kontoutskrifter og forventede leveringstider kontrolleres. En manglende eller forsinket fil gir et varsel før noen stoler på kontantposisjonen.
En nøkkel eller et sertifikat er i ferd med å utløpe
Signeringsnøkler og kanalsertifikater følges opp med utløpsdatoer, og fornyelsen starter tidlig nok til å avtale den nye nøkkelen 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ørsmål og svar
Host-to-host, EBICS eller bank-API-er: hva bør vi bruke?
Banken bestemmer vanligvis. Host-to-host over SFTP er den mest utbredte kanalen for bedrifters betalingsfiler. EBICS er vanlig hos banker i Tyskland, Frankrike og nabolandene. Bank-API-er passer for sanntidssaldo og sanntidsbetalinger der banken tilbyr det. Mange selskaper bruker mer enn én, og integreringslaget skjuler forskjellen for ERP-systemet.
Bør vi motta kontoutskrifter i camt.053 eller MT940?
Der banken tilbyr begge, har camt.053 rikere strukturerte remitteringsopplysninger, som gjør automatisk avstemming mer pålitelig. MT940 er fortsatt mye brukt og fungerer godt i mange tilfeller. Vi kan ta imot begge, konvertere dem til samme interne modell og flytte hver bank fra MT940 til camt.053 når det passer deg og banken.
Kan vi se kontantposisjonen i løpet av dagen?
Ja, hvis bankene dine leverer intradagrapporter. De kommer som camt.052- eller MT942-meldinger, eller via et saldo-API. Vi henter dem etter den planen hver bank støtter og viser dem ved siden av kontoutskriftene ved dagens slutt, slik at treasury-teamet ditt ser forventede og faktiske posisjoner før innleveringsfristene.
Kan vi spore hvem som godkjente og sendte en betaling?
Ja. Godkjenningen blir i ERP-systemet med de eksisterende kontrollene. Integreringslaget logger hver fil det lager, signerer, sender og mottar, med tidsstempler, identifikatorer og den tekniske kontoen som brukes. Loggen kobler hver betaling i bankens statusrapport tilbake til ERP-dokumentet og godkjennerne.
Vi har flere banker. Er hver av dem et eget prosjekt?
Nei. Integreringslaget, den interne betalingsmodellen og avstemmingsreglene bygges én gang. Hver ny bank legger til sin egen formatvariant, kanal og kundeetableringstrinn, som er mindre arbeid. Vi kobler vanligvis til banken med størst volum først og legger til de andre i rekkefølge.
Hvordan testes tilkoblingen før idriftsettelse?
Hver bank stiller med et testmiljø eller en testprosess. Vi avtaler et sett testtilfeller med banken som dekker hver betalingstype, avvisninger og kontoutskrifter, kjører dem og tar vare på dokumentasjonen. Når banken godkjenner, går vi i drift med en liten første betalingskjøring og sammenligner resultatene før vi flytter resten.
Start med en samtale, ikke en kontrakt.
Fortell oss hva du trenger å bygge, koble sammen eller sikre. En arkitekt går gjennom det med deg og anbefaler deretter hvor du bør starte.
Hva skjer videre
Avtale tid
Teamet vårt sender deg en e-post for å avtale tid til samtalen.
Forhåndssamtale
En gratis forhåndssamtale på 30 minutter på nett: vi går gjennom målene, systemene og begrensningene dine.
Modenhetsvurdering
I en gratis modenhetsvurdering innen 48 timer kontrollerer en ledende arkitekt prosjektet ditt mot definisjonen av klar (6 punkter) og anbefaler sporet som passer.
Valg av spor
Prosjekter med definert omfang får et bindende forslag innen 3 til 5 virkedager. Prosjekter i konseptfasen starter i Blueprint Studio. Et system i drift som svikter, er udokumentert eller trenger integrasjon, starter med en diagnose på 1 til 2 uker. Blueprint Studio og diagnosen har hver en fastpris som angis i forslaget.