Betalningsfiler och avstämning mellan ERP och bank
ERP till bank: betalningsfiler ut, kontoutdrag in, avstämt
Betalningar som ISO 20022 pain.001 över host-to-host-SFTP eller bank-API:er, med camt.053- och MT940-kontoutdrag som matchas mot huvudboken.
Ritning
Rulla i sidled för att se hela ritningen.
ERP till bank: betalningar ut, kontoutdrag in
Godkända betalningar lämnar ERP som signerade ISO 20022-filer över en host-to-host-kanal. Statusrapporter och kontoutdrag kommer tillbaka samma väg och matchas mot öppna poster. Avvisningar och omatchade rader går till ditt team med orsaken bifogad.
- Primärt flöde
- Asynkront
- Undantagsväg
Flödet i 10 steg
Flödet, steg för steg
- Från ERP till Integrationslager: Godkänd betalningskörning, över REST/JSON · IDoc (primärt flöde).
- Från Integrationslager till Säker bankkanal: Signerad och krypterad betalningsfil, över ISO 20022 pain.001 · OpenPGP (primärt flöde).
- Från Säker bankkanal till Bank: Levererad till banken, över SFTP H2H (primärt flöde).
- Från Bank till Säker bankkanal: Statusrapporter och kontoutdrag, över pain.002 · camt.053 · MT940 (asynkront).
- Från Säker bankkanal till Integrationslager: Inhämtade och validerade, över SFTP H2H (asynkront).
- Från Integrationslager till Avstämningsmotor: Kontoutdragsrader, över camt.053 (asynkront).
- Från Avstämningsmotor till ERP: Matchade poster bokförda, över REST/JSON (primärt flöde).
- Från Integrationslager till Treasury- och ekonomiteam: Avvisade betalningar, med orsakskod, över pain.002 RJCT (undantagsväg).
- Från Avstämningsmotor till Treasury- och ekonomiteam: Omatchade rader: en avstämningsdifferens (undantagsväg).
- Från Treasury- och ekonomiteam till ERP: Korrigerade och skickade igen (undantagsväg).
Översikt
Det här är flödet mellan ett ERP-system och dess banker: godkända betalningar går ut och statusrapporter och kontoutdrag kommer tillbaka. Det är kopplingen som många finansavdelningar fortfarande sköter för hand, via bankportaler och kalkylark, och den där ett fel kostar pengar.
Referensdesignen lägger ett integrationslager mellan ERP-systemet och varje bank. Lagret mappar betalningarna till bankens variant av ISO 20022 pain.001, signerar och krypterar dem och levererar dem över host-to-host-SFTP, EBICS eller bankens API. Statusrapporter och kontoutdrag kommer tillbaka samma väg och matchas mot öppna poster i ERP-systemet.
Felflödet är lika noggrant utformat som normalflödet. En avvisad betalning kommer tillbaka med bankens orsakskod. En kontoutdragsrad som inte matchar blir en avstämningsdifferens som en namngiven person åtgärdar. Inget tappas bort och inget bokförs två gånger.
Så fungerar flödet
Godkänn betalningskörningen
ERP-systemet tar fram betalningskörningen och dina godkännare släpper den, som i dag. Integrationslagret plockar bara upp godkända körningar.
Mappa, signera och kryptera
Lagret mappar varje betalning till bankens pain.001-variant, validerar den och signerar och krypterar filen som banken kräver.
Leverera till banken
Filen går över den överenskomna kanalen, host-to-host-SFTP, EBICS eller bankens API, före bankens stopptid.
Ta emot status och kontoutdrag
Banken returnerar pain.002-statusrapporter för varje fil och betalning samt camt.053- eller MT940-kontoutdrag vid dagens slut.
Samla in och validera
Lagret hämtar varje rapport, kontrollerar den för luckor och dubletter mot kontoutdragets sekvensnummer och tolkar den till rader.
Matcha och bokför
Kontoutdragsrader matchas mot öppna poster med de regler du godkänt, och matchade poster bokförs i ERP-systemet.
När något går fel
En betalning avvisas
pain.002-rapporten innehåller bankens orsakskod. Betalningen markeras som avvisad i ERP-systemet och skickas till ditt treasuryteam för rättelse och ny inlämning.
En kontoutdragsrad matchar inte
Raden blir en avstämningsdifferens med de troligaste kandidaterna och orsaken till att matchningen misslyckades. Ditt team åtgärdar den, och reglerna kan lära av den.
En fil saknas eller är sen
Kontoutdragets sekvensnummer och förväntade leveranstider kontrolleras. En fil som saknas eller är sen larmar innan någon förlitar sig på kassapositionen.
En nyckel eller ett certifikat håller på att gå ut
Signeringsnycklar och kanalcertifikat följs med sina utgångsdatum, och förnyelsen startar tidigt nog för att den nya nyckeln ska hinna avtalas med banken.
Standarder och system
- Bankstandarder och kanaler
- ISO 20022
- pain.001
- pain.002
- camt.052
- camt.053
- camt.054
- MT940
- MT942
- SFTP (H2H)
- EBICS
- Swift
- OpenPGP
Frågor och svar
Host-to-host, EBICS eller bank-API:er, vilket bör användas?
Banken bestämmer oftast. Host-to-host-SFTP är den vanligast erbjudna kanalen för företags betalningsfiler. EBICS är vanligt hos banker i Tyskland, Frankrike och grannländer. Bank-API:er passar för saldon i realtid och omedelbara betalningar där banken erbjuder dem. Många företag använder mer än en kanal, och integrationslagret döljer skillnaden för ERP-systemet.
Bör camt.053 eller MT940 användas för kontoutdrag?
Där banken erbjuder båda innehåller camt.053 rikare, strukturerad betalningsinformation, vilket gör automatisk matchning mer tillförlitlig. MT940 används fortfarande brett och fungerar bra i många fall. Vi kan ta emot båda, omvandla dem till samma interna modell och flytta varje bank från MT940 till camt.053 när det passar dig och banken.
Går det att se kassapositionen under dagen?
Ja, om dina banker tillhandahåller rapporter under dagen. De kommer som camt.052- eller MT942-meddelanden eller via ett saldo-API. Vi hämtar dem enligt det schema varje bank stöder och visar dem bredvid kontoutdragen vid dagens slut, så att treasuryteamet ser förväntade och faktiska positioner före stopptiderna.
Går det att spåra vem som godkände och skickade en betalning?
Ja. Godkännandet stannar i ERP-systemet med dess befintliga kontroller. Integrationslagret loggar varje fil det skapar, signerar, skickar och tar emot, med tidsstämplar, identifierare och det tekniska konto som används. Loggen kopplar varje betalning i bankens statusrapport tillbaka till ERP-dokumentet och dess godkännare.
Flera banker: blir varje bank ett eget projekt?
Nej. Integrationslagret, den interna betalningsmodellen och matchningsreglerna byggs en gång. Varje ny bank tillför sin egen formatvariant, kanal och introduktionssteg, som är mindre delar av arbetet. Vi kopplar vanligen in banken med störst volym först och lägger till de andra i tur och ordning.
Hur testas kopplingen före driftsättning?
Varje bank tillhandahåller en testmiljö eller en testprocess. Vi kommer överens om en uppsättning testfall med banken, som täcker varje betalningstyp, avvisningar och kontoutdrag, kör dem och sparar underlaget. När banken godkänt går vi i drift med en liten första betalningskörning och jämför resultaten innan resten flyttas.
Börja med ett samtal, inte ett avtal.
Berätta vad du behöver bygga, koppla samman eller skydda. En arkitekt går igenom det med dig och rekommenderar sedan var du ska börja.
Vad som händer härnäst
Vi enas om en tid
Vårt team mejlar dig för att enas om en tid för samtalet.
Förberedande samtal
En kostnadsfri förkonsultation online i 30 minuter: vi går igenom dina mål, system och begränsningar.
Mognadsgenomgång
I en kostnadsfri mognadsgenomgång på 48 timmar prövar en ledande arkitekt ditt projekt mot de sex kriterierna för Definition of Ready och rekommenderar det spår som passar.
Val av spår
Projekt med tydlig omfattning får ett bindande förslag inom 3 till 5 arbetsdagar. Projekt i konceptfasen börjar i Blueprint Studio. Ett system i drift som fallerar, är odokumenterat eller behöver integreras börjar med en diagnostik på 1 till 2 veckor. Blueprint Studio och diagnostiken har var sitt fasta pris som anges i förslaget.