본 사례는 실제 외주 프로젝트 수행 기록을 바탕으로 작성했습니다.
청구서 발행보다 어려웠던 것은 입금 한 줄을 어느 채권에 반제할지 정하는 일이었습니다
저희는 OO콘텐츠 에이전시의 재무운영팀입니다. 프로젝트 검수완료 뒤 회계 SaaS에서 청구서를 만들고 메일로 보내는 과정은 이미 자동화돼 있었습니다. 하지만 실제 미수관리 업무는 청구서 발행이 아니라 은행 거래내역의 입금을 열린 채권과 연결하는 데서 막혔습니다.
거래처 법인명이 아니라 대표자명·브랜드명·관계사명으로 들어오는 타명 입금이 있었고, 여러 프로젝트의 청구금액을 한 번에 보내는 합산 입금, 한 청구를 계약금과 잔금으로 나눠 보내는 부분 입금도 있었습니다. 수수료나 원천징수, 상계 때문에 청구액과 다른 금액이 들어오거나 과입금되는 경우도 있었습니다. 적요에 청구번호가 없으면 입금자명·금액·입금일·거래처의 평소 지급패턴까지 봐야 후보를 좁힐 수 있었습니다.
독촉도 지급기한만 보고 할 수 없었습니다. “금요일 지급 예정”, “검수 이슈 정리 뒤 입금”, “세금계산서 수정 발행 후 처리” 같은 약속이 메일에 남아 있으면 연락을 보류해야 했습니다. 입금 후보가 아직 대사되지 않은 거래처에 독촉 메일이 나가면 고객 신뢰를 해칠 수 있어, 담당자는 통장·청구대장·프로젝트 상태·메일 스레드를 함께 확인했습니다.
기존 AI는 리마인드 문구는 썼지만 은행·회계·메일의 상태를 확인하지 못했습니다
일반적인 AI는 미수 안내 메일을 정중하게 쓰거나 사용자가 올린 두 엑셀을 금액 기준으로 비교할 수 있었습니다. 그러나 담당자의 인증이 필요한 기업뱅킹에서 신규 입금 거래를 조회하고, 회계 SaaS의 열린 청구 건과 연결하고, 메일함의 최근 지급 약속과 분쟁·검수 보류 내용을 확인하는 일은 하지 못했습니다.
부분 입금을 ERP 고객 수금전표로 반영한 뒤 미결잔액을 유지하거나, 합산 입금을 여러 청구에 배분하고 개별 미결항목과 반제하거나, 이미 연결한 은행 거래를 중복 전표 처리하지 않도록 상태를 이어 가는 것도 어려웠습니다. 그래서 AI가 리마인드 초안을 만들어도 실제 발송 전에는 사람이 모든 시스템을 다시 열어 “입금이 전표와 채권에 반영됐는지, 지금 연락해도 되는지”를 확인해야 했습니다.
yaap에 문의해 입금대사-미수후속 플러그인을 만들었습니다
플러그인의 입력은 ERP의 고객별 미결채권, 기업뱅킹 입금 거래, 프로젝트 검수·분쟁 상태, 거래처별 입금자명 이력, 수금 관련 메일 스레드였습니다. 출력은 입금 연결 후보, 부분·합산·과입금 및 타명 입금 예외, ERP 고객 수금전표·반제 준비본, 반영 후 미결잔액, 연락 보류 목록과 승인용 리마인드 초안이었습니다. 자동 전기나 자동 메일 발송은 하지 않고 담당자 승인 앞까지 준비했습니다.
1. ERP 미결채권과 신규 입금 조회 — 담당자가 허용한 세션에서 ERP의 고객·전표·청구번호·지급기한·미결금액과 은행의 입금일·입금자명·금액·적요를 가져왔습니다. 마지막 대사시점 이후 거래만 조회해 같은 은행 거래의 중복 처리를 막았습니다.
2. 입금 연결 후보 생성 — 거래처명과 기존 타명 입금 이력, 금액, 지급기한, 적요의 청구번호·프로젝트명을 조합해 후보를 제시했습니다. 확실한 근거가 없는 건은 임의로 매칭하지 않고 상대 확인 대상으로 남겼습니다.
3. 반제 예외 분리 — 한 청구에 여러 입금이 연결되는 부분 입금, 한 입금이 여러 청구와 이어지는 합산 입금, 과입금·차감입금·타명 입금·중복 연결 후보를 별도 대기열로 만들었습니다. 후보 배분 뒤에도 청구별 잔액이 보이도록 했습니다.
4. 메일 약속과 연락 보류 확인 — 거래처별 최근 수금 메일에서 지급 예정일, 수정 세금계산서 요청, 검수·분쟁 상태를 찾아 청구 건에 연결했습니다. 입금 후보, 유효한 지급 약속, 내부 보류 사유가 있는 건은 리마인드 대상에서 제외했습니다.
5. 수금전표·반제 준비와 후속처리 — 회계 담당자가 입금 연결과 배분 방식을 승인하면 ERP 고객 수금전표와 미결항목 반제 준비본을 만들고, 반영 결과의 잔액을 다시 확인했습니다. 미결로 남고 연락 가능한 건에만 청구번호·금액·지급기한이 들어간 메일 초안을 만들었습니다. 실제 전기와 고객 발송은 담당자가 진행했습니다.
통장 전체가 아니라 연결되지 않은 입금과 실제 연락할 미수 건만 보게 됐습니다
이전에는 월말마다 통장 거래를 첫 줄부터 훑으며 청구대장에 표시했습니다. 지금은 연결 근거가 충분한 후보와 예외가 나뉘고, 담당자는 부분·합산·과입금처럼 배분 판단이 필요한 거래와 출처를 알 수 없는 입금만 확인합니다.
미수 후속업무도 달라졌습니다. 지급기한이 지났다는 이유만으로 모두 연락하지 않고, 은행 입금이 ERP 수금전표와 미결항목에 반영됐는지 확인한 뒤 남은 채권만 봅니다. 입금 후보와 메일의 지급 약속, 검수·분쟁 보류를 제외하면 실제 연락할 건만 남습니다. 전기·반제 결정과 고객 연락은 사람이 하지만, 통장부터 ERP 잔액과 보류 사유까지 이어 보는 반복 탐색은 플러그인이 맡습니다.