ERP-은행 지급 파일 및 대사
ERP에서 은행으로: 지급 파일은 나가고, 거래 명세서는 돌아와 대사됩니다
ISO 20022 pain.001로 작성한 지급을 호스트 간 SFTP 또는 은행 API로 보내고, camt.053 및 MT940 명세서를 원장과 대사합니다.
블루프린트
옆으로 스크롤하여 전체 그림을 확인하십시오.
ERP에서 은행으로: 결제는 나가고, 거래 명세서는 들어옵니다
승인된 결제는 서명된 ISO 20022 파일로 호스트 간 채널을 통해 ERP를 떠납니다. 상태 보고서와 거래 명세서도 같은 경로로 돌아와 미결 항목과 대사됩니다. 거절된 결제와 미매칭 항목은 사유와 함께 귀사 팀에 전달됩니다.
- 기본 흐름
- 비동기
- 예외 경로
10단계로 된 흐름
단계별 흐름
- ERP에서 통합 계층로: 승인된 결제 배치, REST/JSON · IDoc 사용 (기본 흐름).
- 통합 계층에서 보안 은행 채널로: 서명 및 암호화된 지급 파일, ISO 20022 pain.001 · OpenPGP 사용 (기본 흐름).
- 보안 은행 채널에서 은행로: 은행으로 전송됨, SFTP H2H 사용 (기본 흐름).
- 은행에서 보안 은행 채널로: 상태 보고서 및 거래 명세서, pain.002 · camt.053 · MT940 사용 (비동기).
- 보안 은행 채널에서 통합 계층로: 수집 및 검증됨, SFTP H2H 사용 (비동기).
- 통합 계층에서 대사 엔진로: 거래 명세서 항목, camt.053 사용 (비동기).
- 대사 엔진에서 ERP로: 매칭된 전기 처리, REST/JSON 사용 (기본 흐름).
- 통합 계층에서 자금 관리 및 재무 팀로: 거절된 결제, 사유 코드 포함, pain.002 RJCT 사용 (예외 경로).
- 대사 엔진에서 자금 관리 및 재무 팀로: 미매칭 항목: 대사 불일치 (예외 경로).
- 자금 관리 및 재무 팀에서 ERP로: 수정 후 재제출 (예외 경로).
개요
이것은 ERP와 거래 은행 사이의 흐름입니다. 승인된 지급이 나가고 상태 보고서와 거래 명세서가 돌아옵니다. 많은 재무 팀이 여전히 은행 포털과 스프레드시트로 수작업 처리하는 연결이며, 오류가 발생하면 비용이 드는 연결입니다.
참조 설계는 ERP와 각 은행 사이에 통합 계층을 둡니다. 이 계층은 지급을 은행별 ISO 20022 pain.001 변형으로 매핑하고, 서명·암호화한 뒤 호스트 간 SFTP, EBICS 또는 은행 API로 전달합니다. 상태 보고서와 거래 명세서도 같은 경로로 돌아오며 ERP의 미결 항목과 대사됩니다.
실패 경로도 정상 경로만큼 신중하게 설계합니다. 거절된 지급은 은행의 사유 코드와 함께 돌아옵니다. 대사되지 않는 명세서 항목은 지명된 담당자가 해소할 대사 차이가 됩니다. 누락되는 것도, 두 번 전기되는 것도 없습니다.
흐름 방식
지급 실행 승인
귀사 ERP가 지급 실행을 생성하고 지금처럼 승인자가 이를 승인합니다. 통합 계층은 승인된 런만 가져옵니다.
매핑, 서명 및 암호화
통합 계층이 각 지급을 은행의 pain.001 변형으로 매핑해 검증하고, 은행 요건에 따라 파일에 서명하고 암호화합니다.
은행으로 전달
파일은 합의된 채널인 호스트 간 SFTP, EBICS 또는 은행 API를 통해 은행의 마감 시간 전에 전달됩니다.
상태 보고서 및 명세서 수신
은행은 파일과 각 지급에 대한 pain.002 상태 보고서를, 일과 종료 시에는 camt.053 또는 MT940 명세서를 돌려줍니다.
수집 및 검증
통합 계층이 각 보고를 수집하고, 명세서 일련번호와 대조해 누락과 중복을 확인한 뒤 항목 단위로 파싱합니다.
대사 및 전기
거래 명세서 항목을 승인된 규칙으로 미결 항목과 대사하고, 대사된 항목은 ERP에 전기합니다.
실패 시 동작
지급 거절
pain.002 보고에 은행의 사유 코드가 담깁니다. ERP에서 해당 지급은 거절로 표시되고, 귀사 자금 팀이 수정해 다시 제출하도록 전달됩니다.
거래 명세서 항목 불일치
해당 항목은 가능한 후보와 실패 사유를 함께 담은 대사 차이가 됩니다. 귀사 팀이 이를 해소하며, 규칙은 그 결과에서 학습할 수 있습니다.
파일 누락 또는 지연
명세서 일련번호와 예상 도착 시간을 확인합니다. 파일이 누락되거나 늦어지면 누구도 자금 포지션에 의존하기 전에 경보를 발생시킵니다.
키 또는 인증서 만료 임박
서명 키와 채널 인증서를 만료일과 함께 관리하며, 은행과 새 키를 합의할 수 있도록 갱신을 충분히 앞서 시작합니다.
표준 및 시스템
- 은행 표준 및 채널
- ISO 20022
- pain.001
- pain.002
- camt.052
- camt.053
- camt.054
- MT940
- MT942
- SFTP (H2H)
- EBICS
- Swift
- OpenPGP
질문과 답변
호스트 간, EBICS, 은행 API 중 무엇을 사용해야 합니까?
대개 은행이 정합니다. 호스트 간 SFTP는 기업 지급 파일용으로 가장 널리 제공되는 채널입니다. EBICS는 독일, 프랑스 및 인접 국가 은행에서 흔히 사용됩니다. 은행 API는 은행이 제공하는 경우 실시간 잔액과 즉시 지급에 적합합니다. 여러 채널을 함께 쓰는 기업도 많으며, 통합 계층이 ERP에서는 그 차이를 감춥니다.
camt.053과 MT940 중 어떤 거래 명세서를 받아야 합니까?
은행이 둘 다 제공한다면 camt.053이 더 풍부하고 구조화된 송금 정보를 담아 자동 대사의 신뢰성이 높습니다. MT940도 여전히 널리 쓰이며 많은 경우에 잘 작동합니다. 우리는 둘 다 받아 동일한 내부 모델로 변환하고, 귀사와 은행에 적합한 시점에 각 은행을 MT940에서 camt.053으로 전환할 수 있습니다.
업무 중 자금 포지션을 볼 수 있습니까?
은행이 일중 보고를 제공하면 가능합니다. camt.052 또는 MT942 메시지로, 또는 잔액 API를 통해 제공됩니다. 각 은행이 지원하는 일정에 따라 수집해 일과 종료 명세서와 함께 보여주므로, 귀사 자금 팀이 마감 시간 전에 예상 포지션과 실제 포지션을 확인할 수 있습니다.
누가 지급을 승인하고 전송했는지 추적할 수 있습니까?
가능합니다. 승인은 기존 통제 절차와 함께 귀사 ERP에 남습니다. 통합 계층은 생성·서명·전송·수신한 모든 파일을 타임스탬프, 식별자, 사용한 기술 계정과 함께 기록합니다. 이 기록은 은행 상태 보고서의 각 지급을 ERP 문서와 그 승인자에게 연결합니다.
거래 은행이 여러 곳입니다. 은행마다 별도 프로젝트입니까?
아닙니다. 통합 계층, 내부 지급 모델, 대사 규칙은 한 번 구축합니다. 새 은행마다 자체 포맷 변형, 채널, 온보딩 절차가 추가되며 이는 규모가 더 작은 작업입니다. 보통 거래량이 가장 많은 은행을 먼저 연결하고 나머지를 순서대로 추가합니다.
오픈 전에 연결은 어떻게 테스트합니까?
각 은행이 테스트 환경이나 테스트 절차를 제공합니다. 은행과 테스트 케이스 세트를 합의해 각 지급 유형, 거절, 명세서를 다루고, 실행한 뒤 증빙을 보관합니다. 은행이 승인하면 소규모 첫 지급 실행으로 오픈하고 결과를 비교한 뒤 나머지를 이전합니다.
계약이 아니라 대화로 시작하십시오.
구축하거나 연결하거나 보호할 대상을 알려 주십시오. 아키텍트가 함께 검토한 뒤 시작 지점을 제안합니다.
다음 단계
일정 협의
팀이 이메일로 연락해 세션 시간을 협의합니다.
사전 컨설팅 세션
무료 30분 온라인 사전 컨설팅 세션에서 목표, 시스템, 제약 조건을 함께 검토합니다.
준비도 검토
무료 48시간 준비도 검토에서 프린시펄 아키텍트가 프로젝트를 6개 항목의 준비 완료 정의에 비추어 점검하고 적합한 트랙을 권고합니다.
트랙 선택
범위가 준비된 프로젝트는 영업일 기준 3~5일 이내 구속력 있는 제안서를 받습니다. 개념 단계 프로젝트는 블루프린트 스튜디오에서 시작합니다. 장애가 있거나 문서화되지 않았거나 통합이 필요한 운영 시스템은 1~2주 진단으로 시작합니다. 블루프린트 스튜디오와 진단은 각각 고정 비용이며 제안서에 명시됩니다.