일본 시메비(締日) 지급 캘린더가
대부분의 AP팀이 생각하는 것보다 더 어려운 이유

시메비(締日) 시스템: 서른 명이 설계한 지급 달력

일본의 청구 주기 시스템, 즉 시메비(締日) 관행은 단일 시스템이 아닙니다. 이는 서로 다른 30개의 시스템으로, 각각은 한 구매자와 한 공급자 간의 계약에 의해 정의됩니다. 계약은 두 가지를 명시합니다: 청구 기간이 마감되는 날(마감일, 締日)과 지급이 이루어져야 하는 개월 수(지급 조건, 예: 翌月末払い, 翌々月10日払い와 같은 간결한 구문으로 표현). 30개 공급업체로부터 구매하는 회사는 최대 30개의 서로 다른 마감일과 지급 조건 조합을 가지게 됩니다. 각 공급업체가 관계 시작 시 자신의 조건을 협상했고, 그 조건은 구매 계약에 포함되어 있으며, 업계 기관이나 플랫폼에 의해 표준화되지 않았기 때문입니다.

가장 일반적인 조합은 소수에 불과하지만, 그 소수조차도 단일 달력보다는 큽니다:

표는 구조적 문제를 드러냅니다: 동일한 청구서 날짜(3월 10일)가 발행한 공급업체에 따라 4개의 다른 지급 마감일을 생성합니다. 공급업체 A와 B는 각각 15일과 20일에 마감되며, 둘 다 4월 말까지 지급을 요구합니다. 공급업체 C는 월말에 마감되지만 5월 10일까지 지급을 요구합니다. 공급업체 F는 10일에 마감되며 4월 25일까지 지급을 원합니다. AP 담당자는 달력 날짜 '3월 10일'만 보고 언제 지급해야 할지 알 수 없습니다. 청구서 PDF에 텍스트로 포함된 지급 조건 문자열(구조화된 데이터 필드가 아님)은 매월 모든 청구서에 대해 읽고, 구문 분석하고, 달력 날짜로 변환되어야 합니다. 30개 공급업체에 걸쳐 AP 팀은 동시에 30개의 다른 지급 달력을 운영하고 있으며, 어떤 공급업체의 달력도 다른 공급업체의 달력과 아무런 관계가 없습니다.

이것은 일본 특유의 관행이 아닙니다. 이는 각 쌍무 계약이 자체 조건을 정의하는 청구 시스템의 직접적인 결과입니다. 대부분의 국가에서는 Net 30, Net 60 또는 Net 90(송장일 기준 고정 일수)을 사용합니다. 일본은 두 부분으로 구성된 시스템을 사용합니다: 마감일(締日)과 지급 지연(支払遅延)이며, 지급 지연은 일수가 아닌 월 단위로 표현되며 실제 일수는 월 길이에 따라 달라집니다. 4월은 30일, 5월은 31일, 2월은 28일 또는 29일입니다. 3월 10일자 송장에 대한 末日締翌月末払い 조건의 지급 기일은 4월 30일입니다(마감일인 3월 31일부터 4월 30일까지 20일의 지연). 동일 조건의 3월 25일자 송장의 지연도 4월 30일입니다(마감일 기준 30일 지연). 이는 마감일 자체가 월 길이에 따라 달라지기 때문입니다. Net 30 시스템은 두 송장 모두 송장일 기준 동일한 지급일을 제공합니다. 시메비(締日) 시스템은 마감일 기준 동일한 지급일을 제공합니다. AP 담당자는 두 가지를 모두 추적해야 합니다.

NetSuite Japan 현지화 문서는 이를 명확히 설명합니다: "기업은 거래를 시작하기 전에 고객과 마감일을 합의합니다. 지급 기일은 고정되어 있으므로 마감일과 지급 기일 사이의 일수는 각 월의 일수에 따라 달라집니다." 주요 ERP 시스템은 시메비(締日) 로직을 기본적으로 처리합니다. 단, 누군가가 이미 각 공급업체의 마감일과 지급 기일을 공급업체 마스터에 입력한 경우에 한합니다. ERP 이전 단계의 격차는 지급 조건을 송장 PDF에서 추출하여 시스템에 처음 입력하는 것입니다.

서른 개의 공급업체, 서른 개의 달력, 누구도 소유하지 않은 하나의 마감일

서른 개의 공급업체 관계를 관리하는 AP 팀은 월별로 하나의 지급 마감일에 직면하지 않습니다. 매월 2~3개의 달력 날짜에 분산된 서른 개의 지급 마감일에 직면하며, 각각은 해당 월의 다른 날에 마감되는 서로 다른 마감일에 의해 촉발됩니다. 실질적인 결과는 산술적 어려움이 아닙니다(유능한 AP 담당자는 "末日締翌々月10日払い"를 몇 초 만에 해석할 수 있습니다). 실질적인 결과는 달력이 누군가 각 송장을 개별적으로 확인하기 전까지는 보이지 않는다는 것입니다.

미국 기반 AP 팀은 송장 날짜 목록을 훑어보고 정신적으로 30일을 더할 수 있습니다. 일본 기반 AP 팀은 송장 날짜 목록을 전혀 훑어볼 수 없습니다. 송장 날짜만으로는 정보가 불충분하기 때문입니다. 지급 기일을 알 수 있는 유일한 방법은 각 송장의 지급 조건 필드를 읽는 것입니다. 서른 개의 송장이 도착하면 AP 팀은 서른 개의 지급 조건 필드를 읽고 서른 개의 기일을 계산합니다. 하나의 송장 지급 조건을 잘못 읽어 "20日締翌月末払い"를 "末日締翌月末払い"로 혼동하는 경우(마감일이 10일 차이 나기 때문에) 기일은 동일할 수 있지만(둘 다 다음 달 말일) 회계 기간 분류는 잘못될 수 있습니다. 비용이 총계정원장에서 다른 월에 속하게 되어 분기 재무제표와 소비세 신고에 영향을 미칩니다.

달력의 분산은 부서 간에 더욱 심화됩니다. 자금 팀은 운전자본 관리를 위해 날짜별 총 현금 유출액을 알아야 합니다. 조달 팀은 공급업체의 지급 조건이 마지막 계약 갱신 이후 변경되었는지 알아야 합니다. 세무 팀은 어떤 송장이 어떤 소비세 신고 기간에 속하는지 알아야 합니다. 각 팀은 AP 팀에 동일한 데이터의 다른 관점(날짜별, 공급업체별, 세무 기간별)을 요청하며, AP 팀은 각각 개별적으로 분석해야 하는 내장된 지급 조건을 가진 서른 개의 개별 송장을 보고 있기 때문에 먼저 서른 개의 송장을 모두 스프레드시트에 입력한 후 해당 스프레드시트를 조작하지 않고는 이러한 관점을 생성할 수 없습니다. 데이터 입력 단계가 병목 현상입니다. 달력 문제는 데이터 추출 문제의 하류에 있습니다.

지급 기한을 놓쳤을 때의 실제 비용 — 지연 손해금 그 이상

공급업체에 대한 지급 기한을 놓쳤을 때 눈에 보이는 비용은 법정 지연 손해금(遅延損害金, chien songaikin)입니다. 일본 상법(商法) 제514조에 따라 기업 간 상거래의 법정 이율은 연 6%입니다. 50만 엔짜리 청구서를 30일 늦게 지급하면 약 2,466엔의 지연 손해금이 발생합니다. 이는 대부분의 AP팀이 계산하기보다는 면제를 협상하는 쪽을 선택할 만큼 적은 금액이지만, 12개월 동안 30개 공급업체에 걸쳐 누적되면 연간 감사에서 하나의 항목이 될 만큼 큰 금액입니다.

그러나 법정 지연 손해금은 회계 부서가 볼 수 있는 비용입니다. 볼 수 없는 비용은 더 크고 측정하기 어렵습니다:

공급업체 관계 악화. 계약서에 10일로 명시된 지급일을 31일에 받은 공급업체는 즉시 법적 조치를 취하지 않습니다. 정중한 알림을 보냅니다. 두 번째 지연 지급은 조달 관리자에게 전화를 걸게 만듭니다. 세 번째 지연 지급은 공급업체의 행동을 바꿉니다: 선지급 요구, 일방적인 신용 조건 단축, 성수기 구매자 주문 우선순위 하향 조정, 또는 구매자의 미수금을 감당하는 운전자본 비용을 보상하기 위해 다음 계약 협상에서 단가를 인상할 수 있습니다. 이러한 조정은 '지연 지급 대응'으로 항목화되지 않습니다. 이는 다음 구매 주문서의 단가에 포함되어, 이를 초래한 AP팀에는 보이지 않습니다.

현금 흐름 예측 오류. 지급 일정이 잘못되어 5월 10일 마감인 청구서 6건이 실수로 5월 31일 마감으로 입력된 경우, 재무팀의 현금 흐름 예측은 21일의 차이 동안 해당 6건의 총액만큼 가용 현금을 과대 계상합니다. 회사는 부정확한 현금 포지션을 바탕으로 지출 결정을 내릴 수 있습니다. 이 오류는 5월 11일, 6개 공급업체가 지급 상태를 문의할 때까지 발견되지 않으며, 그 시점에는 현금이 이미 다른 곳에 할당되어 재무팀은 부족분을 메우기 위해 급히 움직여야 합니다. 이러한 대응 비용(당좌 대월 이자, 다른 공급업체에 대한 지연 지급, 또는 현금 예측 재작업에 소요된 내부 시간 비용)은 지연 지급 비용으로 계상되지 않습니다.

원천징수 이중 노출. 源泉徴収(gensen chōshū) 분류가 있는 공급업체 청구서는 지급 전에 10.21%를 원천징수해야 합니다. AP팀이 지급 기한을 놓치고 동시에 원천징수도 누락한 경우(속도에 쫓겨 처리할 때 흔히 발생하는 복합 오류), 회사는 공급업체에 전액을 지급하고(10.21% 과다 지급) 여전히 원천징수액을 별도 예치금으로 세무서에 납부해야 합니다. 세무서에 대한 원천징수세의 지연 납부는 공급업체에 대한 상업적 지연 지급과는 별도로 자체적인 지연 가산세가 발생합니다. 원천징수 대상 청구서에 대한 한 번의 지급 기한 누락으로 두 개의 별도 가산세 흐름이 발생할 수 있습니다.

하도급법(下請法) 준수 리스크. 일본의 공정거래위원회가 관할하는 하도급법에 따르면, 원사업자가 중소 하도급업체에 대해 물품이나 용역을 인도받은 후 지급 기한은 법적으로 60일 이내입니다. 하도급법상 지연 지급 시 연 14.6%의 벌금이 부과되는데, 이는 상법상 이율의 두 배 이상입니다. 2025년 개정(2026년 1월 시행)으로 약속어음에 의한 지급이 금지되고 적용 범위가 확대되었습니다. 중소 하도급업체에 대한 원사업자에 해당하는 회사가 60일 기한을 놓치는 것은 단순한 공급업체 관계 문제가 아닙니다. 이는 공정거래위원회가 조사할 수 있는 규제 위반입니다.

스프레드시트가 근본 문제를 해결할 수 없는 이유

스프레드시트는 AP팀이 달력을 관리하는 도구입니다. 동시에, 달력 문제가 더 나은 달력 규율만으로는 해결될 수 없는 이유를 가장 명확히 보여주는 도구이기도 합니다. 스프레드시트에는 지급 기한 열이 하나 있습니다. 그 열은 각 송장 PDF에서 지급 조건을 읽고 "末日締翌々月10日払い"를 달력 날짜로 변환하는 사람이 직접 입력해야 합니다. 스프레드시트는 변환 결과를 저장할 수는 있지만, 송장을 읽을 수 없기 때문에 변환 자체를 수행할 수 없습니다.

즉, 스프레드시트의 정확성은 전적으로 사람의 판독 단계에 달려 있습니다. 매달 모든 송장에 대해 AP 담당자가 지급 조건 필드를 읽고, 머릿속으로 분석한 후 스프레드시트에 날짜를 입력합니다. 이 단계는 빠릅니다. 숙련된 담당자는 몇 초 만에 시메비(締日) 문자열을 분석할 수 있습니다. 이 단계의 취약성은 속도가 아니라 완전성에 있습니다. 30개의 송장, 30번의 분석 이벤트, 30번의 마감일(締日) 오독, 지급 시차 오적용, 또는 23번째 송장과 24번째 송장 사이에 전화로 업무가 중단되어 간과된 지급 조건 필드가 발생할 기회가 있습니다. Net 30 시스템에서는 3월 10일자 송장이 항상 4월 9일이 기한입니다. 수식이 사람의 개입 없이 날짜를 생성할 수 있습니다. 그러나 시메비(締日) 시스템에서는 3월 10일자 송장에 지급 조건이 "末日締翌々月10日払い"인 경우 기한은 5월 10일입니다. "3월 10일"이라는 날짜만으로는 아무 소용이 없습니다. 수식은 입력값으로 지급 조건 없이는 실행될 수 없으며, 지급 조건은 스프레드시트가 접근할 수 없는 형식인 송장 PDF에만 존재합니다.

동일한 구조적 격차는 지급 달력에 의존하는 모든 다운스트림 프로세스에도 적용됩니다. 재무팀의 현금 흐름 예측은 AP팀이 입력한 기한만큼만 정확합니다. 세무팀의 소비세 기간 배분은 AP팀이 분석한 마감일(締日)만큼만 정확합니다. 조달팀의 공급업체 지급 조건 감사는 AP팀이 참조한 가장 최근 계약 조건만큼만 정확합니다. 전체 지급 달력은 사람이 PDF를 읽는 기반 위에 세워져 있습니다. 이 기반은 어떤 스프레드시트 기능으로도 강화할 수 없습니다. 스프레드시트는 판독이 이미 이루어진 시점부터 시작되기 때문입니다. 판독 단계에서 오류가 발생하면 스프레드시트는 이를 충실히 저장하고 전파합니다.

대부분의 사람들이 "지급 기한 추적"이라고 부르는 문제는 실제로 두 가지 문제가 결합된 것입니다. 첫 번째 문제는 송장에서 지급 조건을 추출하는 것입니다. PDF에서 "末日締翌々月10日払い"를 읽어 구조화된 데이터로 변환하는 것입니다. 두 번째 문제는 구조화된 납기일을 30개 공급업체에 걸쳐 추적하는 것입니다. 스프레드시트는 두 번째 문제를 해결할 수 있습니다. 첫 번째 문제는 해결할 수 없습니다. 첫 번째 문제, 즉 추출 문제가 대부분의 AP 팀이 이미 보유한 도구로는 달력 문제를 해결할 수 없게 만드는 이유입니다. 일본어 송장 데이터 추출 단계별 가이드에서는 추출 워크플로가 캡처하는 전체 필드 구조(지급 조건 및 계산된 결제일 포함)를 다루며, 이는 달력이 입력값으로 필요로 하는 구조화된 데이터입니다. 송장의 지급 조건과 ERP의 지급일 사이의 동일한 격차가 조달 측면에서 발주-납품-송장 매칭 병목 현상을 유발합니다. 매칭을 위해서는 세 문서가 조건에 동의해야 하는데, 조건은 PDF의 텍스트 문자열로 존재하기 때문입니다.

실제 해결책이 있는 곳 — 그리고 그것이 워크플로 변경이 아닌 이유

일본 AP에서의 달력 문제는 일정 문제로 오진되는 경우가 많습니다. 제안되는 해결책은 대개 "더 나은 달력 관리"입니다. 공유 팀 달력, 자동 알림, 주간 지급 실행 검토 회의 등입니다. 이러한 해결책 중 어느 것도 지급 기한이 날짜가 아닌 텍스트 문자열로 송장에 기재되어 있다는 사실을 바꾸지 않습니다. 더 나은 달력 관리는 달력을 더 보기 좋게 만듭니다. PDF의 텍스트 문자열과 달력 셀의 날짜 사이의 격차를 해소하지는 않습니다.

해결책은 추출 계층, 즉 송장 PDF에서 데이터가 구조화된 형태로 이동하는 단계에 있습니다. 추출 단계에서 원시 지급 조건 텍스트뿐만 아니라 구문 분석된 결제일과 지급 지연을 별도의 구조화된 값으로 생성한다면, 달력은 스스로 채워질 수 있습니다. 결제일(지급 조건에서: 일자 번호 출력) 및 지급 지연 개월 수(지급 조건에서: 개월 수 출력)와 같은 열, 즉 AI가 추출 중에 도출하는 두 개의 계산 열은 "末日締翌々月10日払い"를 결제일: 31, 지급 지연 개월 수: 2(10일 지급)로 변환합니다. 그러면 스프레드시트 수식이 송장 날짜에 결제일과 지급 지연을 더하여 실제 납기일을 계산할 수 있습니다. 추출 단계는 달력에 필요한 구조화된 입력값을 제공합니다. AP 담당자는 더 이상 읽고 구문 분석하지 않습니다. AP 담당자는 검증합니다.

이는 워크플로 변경이 아닙니다. 데이터 파이프라인 변경입니다. 지급 조건을 사람이 해석해야 하는 불투명한 텍스트 문자열이 아닌 구조화된 데이터로 추출하여 송장 PDF를 지급 달력에 직접 연결하는 것입니다. 지급 달력에 공급되는 동일한 파이프라인이 현금 흐름 예측, 소비세 기간 할당, 공급업체 지급 조건 감사에도 공급됩니다. 달력 문제는 달력이 더 좋아져서가 아니라 달력에 공급되는 데이터가 더 이상 사람에 의존하지 않게 되었기 때문에 사라집니다.

동일한 원칙, 즉 구조화된 데이터를 추출하여 문서와 의사 결정 간의 격차를 해소하는 원칙이 일괄 송장 처리 워크플로를 주도합니다. 여기서 30개의 송장이 은행 송금 세부 정보, 원천징수 계산, 결제일별로 그룹화된 지급 일정이 포함된 지급 준비 완료 스프레드시트 하나를 생성합니다. 또한 이는 호주 BAS 신고 분석의 구조적 통찰력을 반영합니다. 양식 작성은 90초가 걸리지만 데이터 준비는 며칠이 걸립니다. 두 경우 모두 눈에 보이는 마감일 뒤에 보이지 않는 데이터 준비 단계가 숨어 있으며, 바로 이 준비 단계에서 추출 계층이 격차를 해소합니다.

FAQ

ERP 시스템이 시메비(締日) 기반 지급 조건을 자동으로 처리할 수 없는 이유는 무엇인가요?

NetSuite, SAP, Oracle E-Business Suite와 같은 ERP 시스템은 일본의 시메비(締日) 기반 지급 조건을 처리할 수 있습니다. 단, 각 공급업체의 마스터 레코드에 해당 조건이 입력된 이후에만 가능합니다. 예를 들어 NetSuite의 Japan Localization 모듈에서는 공급업체별로 마감일 패턴과 지급 기한을 정의할 수 있으며, 시스템이 각 거래의 지급 기한을 자동으로 계산합니다. 문제는 공급업체의 청구서 PDF에서 지급 조건을 추출하여 공급업체 마스터에 처음 입력하는 과정에 있습니다. 신규 공급업체가 "20일 마감 익월 말 지급"이라는 지급 조건이 적힌 첫 번째 청구서를 보내오면, 누군가가 PDF에서 해당 텍스트를 읽고 ERP의 마감일 패턴을 그에 맞게 설정해야 합니다. ERP는 이후의 계산을 처리할 뿐, 초기 추출 작업은 처리하지 않습니다.

일본 기업은 모두 시메비(締日) 기반 지급 조건을 사용하나요?

대부분의 국내 B2B 거래에서 사용됩니다. 이 시스템은 일본 상거래 관행에 깊이 자리 잡고 있습니다. 일부 업종, 특히 다수의 소규모 공급업체를 거래하는 대형 소매업체에서는 개별 청구 주기와 관계없이 "익월 25일 지급"과 같은 고정일 지급 방식으로 전환하기 시작했지만, 시메비(締日) 관행은 여전히 지배적인 모델입니다. 30개 공급업체로부터 청구서를 받는 중견 기업의 경우, 현실적으로 25개 이상의 공급업체가 시메비(締日) 기반 조건을 사용할 것이며, 각 공급업체의 조건은 서로 다를 수 있습니다.

하도급법(下請法)의 60일 제한은 시메비(締日) 기반 지급 조건과 어떻게 상호작용하나요?

하도급법(下請法)은 원사업자가 재화나 용역을 수령한 날로부터 60일 이내에 하수급인에게 대금을 지급하도록 요구합니다. 매월 1일에 납품하는 하수급인과 "말일 마감 익익월 말 지급" 조건을 협상한 원사업자는 납품 시점이 청구 주기와 어떻게 겹치는지에 따라 약 60~90일의 지급 기간에 직면할 수 있습니다. 이처럼 긴 시메비(締日) 지연과 법정 60일 제한이 결합되면 능동적인 모니터링이 필요한 규정 준수 위험이 발생합니다. 하도급법(下請法)에 따른 14.6%의 지연손해금(遅延損害金)은 기업이 범할 수 있는 가장 비용이 많이 드는 달력 오류입니다.

공급업체가 계약 도중 지급 조건을 변경하면 어떻게 되나요?

공급업체는 계약 갱신 시 또는 경우에 따라 청구서에 인쇄된 조건을 일방적으로 업데이트하여 지급 조건을 변경할 수 있습니다. AP팀이 공급업체 마스터의 기존 조건을 사용하여 청구서를 처리하는 동안 공급업체가 이미 새로운 조건으로 전환한 경우, 불일치가 발견될 때까지 해당 공급업체의 지급 일정이 잘못됩니다. 이는 공급업체가 자체 현금 흐름을 개선하기 위해 翌月末払い에서 翌々月払い로 전환할 때 가장 흔히 발생합니다. AP팀은 기존(더 짧은) 일정에 따라 지급하며, 이는 공급업체에 유리하므로 공급업체가 불일치를 알릴 유인이 없습니다. 이러한 불일치는 감사나 현금 흐름 이상 징후가 주목할 때까지 지속됩니다.

아무도 대시보드를 만들지 않는 달력 문제

일본 AP에서의 지급 일정 관리는 증상(지급 기한 미준수)이 일회성 오류처럼 보이고 시스템적 실패로 보이지 않기 때문에 자체 대시보드를 생성하지 않는 문제입니다. 공급업체가 알림을 보냅니다. AP팀이 사과하고 지급을 처리합니다. 건이 종료됩니다. 근본 원인(지급 만기일이 청구서에 날짜가 아닌 텍스트 문자열로만 존재했고, 사람이 이를 해석해야 했으며, 해석을 잘못한 것)은 사고 보고서에 나타나지 않습니다. 이는 어디에도 나타나지 않습니다. 그 이유는 이를 드러낼 데이터(청구서의 지급 조건 대 스프레드시트의 만기일)가 서로 다른 두 시스템에 존재하며, 오류가 비교를 강제하지 않는 한 아무도 이를 비교하지 않기 때문입니다.

격차는 구조적입니다. 청구서는 컴퓨터가 사용할 수 없는 형식(PDF에 포함된 텍스트)으로 지급 조건을 전달합니다. AP팀은 전적으로 사람의 주의력(읽기, 해석, 입력)에 의존하는 단계를 통해 이를 컴퓨터가 사용할 수 있는 형식(스프레드시트의 달력 날짜)으로 변환합니다. 30개 공급업체, 월 30건의 청구서, 연 12개월에 걸쳐 이 단계는 360회 발생합니다. 오류율은 백분율로는 낮지만 절대적인 측면에서는 비용이 많이 듭니다. 각 오류가 공급업체 관계, 현금 흐름 예측, 세무 신고 및 규정 준수 위험으로 이어지기 때문입니다. 해결책은 더 나은 달력이 아닙니다. 해결책은 격차를 해소하는 것입니다. 즉, 추출 단계에서 달력이 직접 소비할 수 있는 구조화된 지급 조건 데이터를 생성하여, 달력이 사람의 청구서 판독이 아닌 청구서 자체에서 파생되도록 하는 것입니다.