다계좌 입금 대사(Reconciliation) 및 미수금 관리 자동화 설계: 동액 청구서 오매칭 방지 아키텍처

[아키텍처 노트 안내]
본 문서는 제이앤코어 오픈 기술 Q&A 44번 문의(복수 은행 법인 계좌 거래내역 수집 및 입금 확인 자동화)를 바탕으로, 거래내역 확보 이후 실무에서 가장 빈번하게 사고가 발생하는 **‘청구-입금 대사(Reconciliation) 및 미수금 정산 파이프라인’**을 구체화한 시스템 설계 노트입니다. 본문의 거래처·금액·테이블 구조는 아키텍처 설명을 위한 레퍼런스 모델입니다.

1. 문제의 본질: ‘거래내역 수집’과 ‘입금 귀속 판단’의 분리

복수의 은행에 개설된 법인 계좌를 매일 순회하며 거래내역 엑셀을 내려받고 미수금 장부와 대조하는 업무는 전형적인 재무·경리 병목 구간입니다. 흔히 이 업무의 자동화를 문의할 때 **‘은행 사이트에서 내역을 자동으로 가져오는 것’**에만 초점을 맞추기 쉽습니다.

그러나 시스템 엔지니어링 관점에서 거래내역 수집(Ingestion)은 전체 파이프라인의 전반부에 불과합니다. 통장 내역을 한 화면에 모두 모았다고 해서 입금 대사가 자동으로 끝나지 않기 때문입니다.

현장에서 수작업 엑셀 대사가 무너지는 지점은 언제나 다음과 같은 비결정적(Non-deterministic) 매칭 상황입니다.

동액 청구서 충돌: A거래처와 B거래처의 미수 청구액이 모두 1,000,000원인데, 통장 적요란에는 법인 상호가 아닌 대표자 개인 성명이나 축약어로 1,000,000원이 입금된 경우.
부분입금(Partial Payment): 1,000,000원 청구 건에 대해 1차로 600,000원만 먼저 입금되고 잔액 400,000원은 주 단위로 나뉘어 입금되는 경우.
합산입금(Lump-sum Payment): 전월 미수금과 당월 청구서 여러 건을 거래처가 임의로 합산하여 단 한 번에 송금한 경우.

단순히 청구금액 == 입금금액 조건으로 자동 완료 처리를 해버리는 어설픈 매크로나 자동화 프로그램은 동일 금액의 엉뚱한 거래처 미수금을 지워버리는 심각한 회계 정합성 오류를 유발합니다. 따라서 ‘내역을 모으는 계층’과 ‘어느 청구에 귀속시킬지 판단하는 대사 계층’을 엄격히 분리하여 설계해야 합니다.

2. 데이터 수집 및 정규화 계층(Normalization Layer): 출처 추적과 멱등성 보장

API 연동이든 기존에 내려받던 은행별 엑셀 파일 업로드든, 첫 단계는 서로 다른 은행의 컬럼 구조를 **단일 표준 트랜잭션 스키마(Canonical Transaction Schema)**로 정규화하는 것입니다.

[다계좌 거래내역 정규화 및 멱등성(Idempotency) 검증 파이프라인]
은행별 원본 파일 (A은행.xls / B은행.xlsx / C은행.csv)
  ├─ 1. 스키마 매핑: [거래일시, 입금액, 출금액, 적요(입금자표기), 잔액] 표준화
  ├─ 2. 계좌 식별자 바인딩: 은행명 단독이 아닌 내부 계좌 고유 ID(Account_UUID) 부여 (동일 은행 다계좌 구분)
  ├─ 3. 원본 추적 메타데이터 보존: (Source_File_ID, Original_Row_No, Raw_Hash) 기록
  └─ 4. 기간 중첩 업로드 방어: 동일 일시·동일 금액·동일 입금자의 실제 연속 입금 vs 단순 파일 재업로드 분리 검증

여기서 핵심은 **원본 역추적성(Traceability)**과 중복 판별 로직입니다.

원본 행 위치 보존: 정규화된 통합 테이블에서 이상 징후가 발견되었을 때, 해당 레코드가 어느 은행의 몇 번째 업로드 파일, 몇 번째 행(Row)에서 유래했는지 즉시 역추적할 수 있어야 합니다.
단순 중복 삭제의 금지: 조회 기간이 겹치는 엑셀 파일을 다시 업로드했을 때 이중 집계를 막아야 하지만, 반대로 '날짜·금액·적요가 같으면 무조건 중복으로 간주해 삭제'해서도 안 됩니다. 실제 영업 현장에서는 동일 거래처가 같은 시각에 같은 금액을 두 번 분할 송금하는 사례가 존재하기 때문입니다. 원본 파일 내 순번과 거래 후 잔액(Balance) 변화를 함께 대조하여 **확정 중복(재업로드)**과 **검토 필요 중복 후보(실제 연속 입금 가능성)**를 분리해야 합니다.

3. 동액 청구서 오매칭 방지: 자동 확정이 아닌 ‘후보군 추론(Candidate Scoring)’

앞서 언급한 예시처럼 A거래처와 B거래처의 미수 청구가 각각 100만 원이고, 통장에는 개인 성명으로 100만 원이 찍힌 상황을 가정해 보겠습니다. 금액만 놓고 보면 두 청구서 모두 매칭 후보입니다.

신뢰할 수 있는 정산 시스템은 근거가 불충분한 상태에서 먼저 조회된 청구서를 임의로 닫지 않습니다. 대신 다음과 같은 매칭 상태 머신(Matching State Machine)을 운영합니다.

매칭 분류 상태	판별 조건 (Rule Engine)	시스템 처리 방식
`AUTO_MATCHED` (단일 확정 후보)	청구 금액 일치 + 거래처 공식 상호(또는 검증된 전용 계좌/고유코드) 정확 일치 + 동액 타 후보 없음	매칭 대기열 최상단에 배치하여 원클릭 일괄 승인 지원
`MULTI_CANDIDATE` (복수 후보 충돌)	입금액과 일치하는 미수 청구서가 2건 이상 존재하거나 입금자 표기가 모호한 경우	자동 확정 차단 → 후보 청구서 리스트(청구일, 거래처, 기입금액, 과거 입금 이력)를 나란히 비교 노출
`PARTIAL_OR_SUM` (부분/합산 후보)	입금자명은 특정 거래처와 매칭되나 입금액이 단일 청구액과 다른 경우	해당 거래처의 미결 청구 목록을 호출하여 잔액 차감 또는 다중 청구 배분 인터페이스로 연결
`UNIDENTIFIED` (미확인 입금)	금액과 입금자 표기 모두 기존 미수 원장과 매칭 근거가 없는 경우	임의 귀속 금지 → ‘미확인 입금 원장’으로 격리 및 영업 담당자 확인 요청 상태 부여

입금자 별칭(Alias) 사전 설계 시 주의점

실무 편의를 위해 “홍길동으로 입금되면 A거래처로 인식하라”는 별칭(Alias) 매핑 기능을 흔히 추가합니다. 그러나 한 명의 대리인이나 대표자가 복수의 법인 거래처를 겸영하며 송금하는 경우, 성명 하나를 특정 거래처에 영구 귀속시키면 다음 달에 오매칭 사고가 발생합니다. 따라서 별칭은 **‘강제 확정 규칙’이 아니라 ‘후보 우선순위 가중치(Hint)‘**로만 작동하도록 설계하고, 매칭 확정 시 어떤 근거로 연결했는지 감사 로그를 남겨야 합니다.

4. 1:1 매칭의 한계 극복: 부분입금 및 합산입금을 위한 `N:M 배분(Allocation)` 데이터 모델

초기 설계에서 가장 흔히 범하는 실수는 청구서(Invoice) 테이블에 입금_ID 컬럼 하나만 두어 1:1 관계로 묶는 것입니다. 이렇게 설계하면 부분입금과 합산입금이 발생하는 순간 시스템이 멈춥니다.

현장 업무를 완벽히 수용하려면 청구 원장과 입금 원장 사이에 입금 배분 매핑(Payment Allocation) 교차 엔티티를 두는 N:M 관계로 설계해야 합니다.

-- 청구(Invoices)와 입금(Bank_Deposits)을 N:M으로 연결하는 배분 원장 구조 예시
CREATE TABLE payment_allocations (
    allocation_id      BIGSERIAL PRIMARY KEY,
    deposit_id         BIGINT NOT NULL REFERENCES bank_deposits(deposit_id),
    invoice_id         BIGINT NOT NULL REFERENCES invoices(invoice_id),
    allocated_amount   NUMERIC(15, 2) NOT NULL CHECK (allocated_amount > 0),
    match_rationale    VARCHAR(100) NOT NULL, -- 'EXACT_NAME', 'MANUAL_SPLIT', 'ALIAS_HINT' 등
    confirmed_by       VARCHAR(50) NOT NULL,
    confirmed_at       TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

이 구조를 적용하면 두 가지 복잡한 현장 케이스가 명확하게 해결됩니다.

부분입금(1개 청구 : N개 입금): 100만 원 청구 건에 1차 입금 60만 원이 배분되면 미수 잔액은 40만 원(부분수금 상태)으로 남고, 추후 40만 원이 추가 입금되어 배분되면 누적 배분액이 100만 원에 도달하여 청구 상태가 완납으로 전환됩니다.
합산입금(N개 청구 : 1개 입금): 거래처가 한 번에 송금한 금액을 여러 건의 미수 청구서에 쪼개어 배분할 수 있으며, 시스템은 배분 합계가 원본 입금액을 초과하지 않는지(SUM(allocated_amount) <= deposit_amount) 트랜잭션 단위로 검증합니다.
임의 차액 소거 금지: 송금 수수료 차감, 상계, 환불, 외화 환차손 등으로 인한 차액은 화면이 임의로 0원 처리하지 않고 별도의 조정 항목(Adjustment Reason)을 명시해 회계 기준에 맞게 마감하도록 통제합니다.

5. 예외 중심(Exception-First) 실무 화면 설계와 사전 검증

담당자가 매일 아침 마주해야 할 화면은 200줄짜리 전체 거래내역 표가 아닙니다. 목표는 200줄을 더 빠르게 스크롤하게 만드는 것이 아니라, 사람이 직접 판단해야만 하는 예외 건(복수 후보 충돌, 입금자 미상, 부분입금 잔액)만 상단에 격리하여 확인 범위를 좁히는 것입니다.

제이앤코어는 정산 시스템 배포 전 반드시 다음과 같은 **오류 주입 테스트(Fault Injection Test)**를 수행합니다.

동일 금액의 서로 다른 거래처 청구 2건 동시 존재 시 자동 확정이 차단되는가?
동일 기간의 거래내역 엑셀 파일을 중복 업로드했을 때 이중 차감이 방지되는가?
잘못 연결된 입금 매칭을 취소(Rollback)했을 때 청구서의 미수 잔액이 정확히 복원되고 취소 이력이 보존되는가?

💡 입금 대사·미수금 정산 및 거래처 통지 자동화 상담

통장에 돈이 들어왔다는 사실과 실제 어느 거래처의 미수금이 정리되었는지를 맞추느라 매일 수작업을 반복하고 계십니까?
대사 완료 후 거래처별로 정산 내역서를 분할해 메일로 발송하는 과정까지 하나의 파이프라인으로 연결하고 싶으십니까? (연관 아키텍처 노트: 거래처별 엑셀 자동 분할 및 메일 오발송 방지 검증 큐 설계 →)

계좌번호와 실명을 가린 현재 관리 파일의 컬럼 구조만 공유해 주시면, 오매칭 없는 안전한 정산 웹 시스템을 설계해 드립니다.