Why the Japanese Shimebi Payment Calendar
Is Harder Than Most AP Teams Realize

The Shimebi System: A Payment Calendar Designed by Thirty Different People

Japan's billing cycle system — the shimebi (締日) convention — is not a single system. It is thirty systems, each defined by a contract between one buyer and one supplier, and the contract specifies two things: the day of the month on which the billing period closes (the settlement day, 締日) and how many months later the payment must arrive (the payment lag, expressed in a compact syntax like 翌月末払い or 翌々月10日払い). A company that buys from thirty suppliers has up to thirty distinct combinations of settlement day and payment lag, because each supplier negotiated its own terms at the start of the relationship, and those terms are embedded in the purchase contract, not standardized by any industry body or platform.

The most common combinations form a small set, but the small set is still larger than a single calendar:

The table reveals the structural problem: the same invoice date — March 10 — produces four different payment due dates depending on which supplier issued it. Suppliers A and B close on the 15th and 20th respectively, both requiring payment by end of April. Supplier C closes at month-end but demands payment by May 10. Supplier F closes on the 10th and wants payment by April 25. The AP clerk cannot look at the calendar date "March 10" and know when to pay. The payment terms string — embedded in the invoice PDF as text, not as a structured data field — must be read, parsed, and converted to a calendar date for every invoice, every month. Across thirty suppliers, the AP team is running thirty different payment calendars simultaneously, and no supplier's calendar has any relationship to any other supplier's calendar.

This is not a Japanese quirk. It is a direct consequence of a billing system where each bilateral contract defines its own terms. Most countries use Net 30, Net 60, or Net 90 — invoice date plus a fixed number of days. Japan uses a two-part system: settlement day plus payment lag, where the payment lag is expressed in months, not days, and the actual number of days varies by month length. April has 30 days; May has 31; February has 28 or 29. The payment due date under 末日締翌月末払い for a March 10 invoice is April 30 — a lag of 20 days from the settlement day (March 31 to April 30). For a March 25 invoice under the same terms, the lag is also April 30 — a lag of 30 days from the settlement day, because the settlement day itself varies by month length. A Net 30 system would give both invoices the same payment date relative to the invoice date. The shimebi system gives them the same payment date relative to the settlement day. The AP clerk must track both.

The NetSuite Japan localization documentation explains this clearly: "companies agree on a closing date with customers before starting business transactions. The payment due date is fixed, which means that the number of days between the closing date and the payment due date varies, depending on how many days each month has." Major ERP systems handle shimebi logic natively — provided someone has already entered the closing date and payment due date for each supplier into the supplier master. The gap is the step before the ERP: getting the payment terms off the invoice PDF and into the system in the first place.

Thirty Suppliers, Thirty Calendars, One Deadline That Nobody Owns

The AP team managing thirty supplier relationships does not face one payment deadline per month. It faces thirty payment deadlines, distributed across two or three calendar dates per month, each one triggered by a different settlement day that closes on a different day of the month. The practical consequence is not arithmetic difficulty — a competent AP clerk can parse "末日締翌々月10日払い" in seconds. The practical consequence is that the calendar is invisible until someone looks at each invoice individually.

A US-based AP team can scan a list of invoice dates and mentally add thirty days. A Japan-based AP team cannot scan a list of invoice dates at all — the invoice date is insufficient information. The only way to know the payment due date is to read the payment terms field on each invoice. If thirty invoices arrive, the AP team reads thirty payment terms fields and calculates thirty due dates. If one invoice's payment terms are misread — if "20日締翌月末払い" is confused with "末日締翌月末払い" because the settlement day differs by ten days — the due date may be the same (both end-of-following-month) but the fiscal-period classification may be wrong. The expense belongs to a different month in the general ledger, which cascades into the quarterly financial statements and the consumption tax return.

The calendar fragmentation compounds across departments. The treasury team needs to know total cash outflow by date to manage working capital. The procurement team needs to know whether a supplier's payment terms have changed since the last contract renewal. The tax team needs to know which invoices fall into which consumption tax reporting period. Each team asks the AP team for a different cut of the same data — by date, by supplier, by tax period — and the AP team, looking at thirty individual invoices each carrying embedded payment terms that must be parsed one at a time, cannot produce any of these views without first entering all thirty invoices into a spreadsheet and then manipulating that spreadsheet. The data entry step is the bottleneck. The calendar problem is downstream of the data extraction problem.

What a Missed Deadline Actually Costs — Beyond the Late Payment Penalty

The visible cost of missing a supplier payment deadline is the statutory late payment interest (遅延損害金, chien songaikin). Under Article 514 of Japan's Commercial Code (商法), the legal interest rate for commercial transactions between companies is 6% per annum. A ¥500,000 invoice paid thirty days late accrues roughly ¥2,466 in late payment damages — an amount small enough that most AP teams would rather negotiate a waiver than calculate the interest, but large enough that, across thirty suppliers over twelve months, the aggregate exposure becomes a line item in the annual audit.

But the statutory penalty is the cost the accounting department can see. The costs it cannot see are larger and harder to measure:

Supplier relationship erosion. A supplier who receives payment on the 31st when the contract specified the 10th does not immediately escalate to legal action. They send a polite reminder. The second late payment triggers a phone call to the procurement manager. The third late payment changes the supplier's behavior: they may begin requesting payment in advance, shortening credit terms unilaterally, deprioritizing the buyer's orders during busy seasons, or adjusting unit prices upward in the next contract negotiation to compensate for the working capital cost of carrying the buyer's receivable. These adjustments are not itemized as "late payment response." They are embedded in the next purchase order's unit price, invisible to the AP team that triggered them.

Cash-flow forecasting error. When the payment calendar is wrong — when six invoices due on May 10 were mistakenly entered as due on May 31 — the treasury team's cash-flow forecast overstates available cash by the total of those six invoices for the twenty-one-day gap. The company may make spending decisions based on an inaccurate cash position. The error is not discovered until May 11, when six suppliers inquire about payment status — at which point the cash has already been allocated elsewhere, and the treasury team must scramble to cover the shortfall. The cost of the scramble — overdraft interest, delayed payments to other suppliers, or the internal time cost of reworking the cash forecast — is not booked as a late payment cost.

Withholding tax double exposure. A supplier invoice carrying a 源泉徴収 (gensen chōshū) classification must have 10.21% withheld before payment. If the AP team misses the payment deadline and also misses the withholding — a common compound error when processing at speed — the company pays the full amount to the supplier (an overpayment of 10.21%) and still owes the withheld amount to the tax office as a separate deposit. Late payment of withholding tax to the tax office accrues its own penalty interest, separate from the commercial late payment to the supplier. One missed payment deadline on a withholding-eligible invoice can generate two separate penalty streams.

The 下請法 (Subcontract Act) compliance risk. For companies that are parent contractors under Japan's Act on Proper Transactions with Small and Medium-Sized Entrusted Business Operators, the legal payment deadline is 60 days from delivery of goods or services. Late payment under the Subcontract Act carries a 14.6% per annum penalty — more than double the Commercial Code rate — enforced by the Japan Fair Trade Commission. A 2025 amendment (effective January 2026) strengthened the Act by prohibiting payment by promissory notes and expanding coverage. For a company that qualifies as a parent contractor to small and medium subcontractors, missing the 60-day window is not a supplier-relationship problem. It is a regulatory violation that the Fair Trade Commission can investigate.

Why the Spreadsheet Cannot Solve the Root Problem

The spreadsheet is the tool AP teams use to manage the calendar. It is also the tool that most clearly demonstrates why the calendar problem is not solvable with better calendar discipline. The spreadsheet has one column for the payment due date. That column must be filled by a human who reads the payment terms off each invoice PDF and converts "末日締翌々月10日払い" into a calendar date. The spreadsheet can store the result of that conversion. It cannot perform the conversion itself, because the spreadsheet cannot read the invoice.

This means the spreadsheet's accuracy depends entirely on the human reading step. Every invoice, every month, the AP clerk reads the payment terms field, parses it mentally, and types a date into the spreadsheet. The step is fast — a competent clerk can parse a shimebi string in seconds. The step's fragility is not in its speed but in its completeness: thirty invoices, thirty parsing events, thirty chances for a misread settlement day, a misapplied payment lag, or a payment terms field that was overlooked because the clerk was interrupted by a phone call between invoice twenty-three and invoice twenty-four. In a Net 30 system, an invoice dated March 10 is always due April 9 — a formula can generate the date without human involvement. In the shimebi system, an invoice dated March 10 with payment terms "末日締翌々月10日払い" is due May 10. The date "March 10" alone is useless. The formula cannot run without the payment terms as input, and the payment terms exist only on the invoice PDF — a format the spreadsheet cannot access.

The same structural gap applies to every downstream process that depends on the payment calendar. The treasury team's cash-flow forecast is only as accurate as the due dates the AP team entered. The tax team's consumption tax period allocation is only as accurate as the settlement days the AP team parsed. The procurement team's supplier payment-term audit is only as accurate as the most recent contract terms the AP team referenced. The entire payment calendar sits on a foundation of human reading of PDFs — a foundation that no spreadsheet function can reinforce, because the spreadsheet starts at the point where the reading has already happened. If the reading step produces an error, the spreadsheet faithfully stores and propagates it.

The problem that most people call "tracking payment deadlines" is actually two problems fused together. The first problem is extracting the payment terms from the invoice — reading "末日締翌々月10日払い" off the PDF and converting it into structured data. The second problem is tracking those structured due dates across thirty suppliers. The spreadsheet can do the second problem. It cannot do the first. The first problem — the extraction problem — is what makes the calendar problem unsolvable with the tools most AP teams already have. The step-by-step guide to extracting Japanese invoice data covers the full field structure that an extraction workflow captures, including payment terms and their computed settlement days — the structured data that a calendar needs as input. The same gap between the payment terms on the invoice and the payment date in the ERP drives the PO-to-delivery-to-invoice matching bottleneck on the procurement side: a match requires the three documents to agree on terms, and the terms live in text strings on PDFs.

Where the Fix Actually Lives — and Why It Is Not a Workflow Change

The calendar problem in Japanese AP is routinely misdiagnosed as a scheduling problem. The proposed fix is usually "better calendar management" — a shared team calendar, automated reminders, a weekly payment-run review meeting. None of these fixes changes the fact that the payment due date is not on the invoice as a date. It is on the invoice as a text string that must be parsed. Better calendar management makes the calendar prettier. It does not close the gap between the text string on the PDF and the date in the calendar cell.

The fix lives at the extraction layer — the step where data moves from the invoice PDF into structured form. If the extraction step produces not just the raw payment terms text but the parsed settlement day and payment lag as separate structured values, the calendar can populate itself. A column like Settlement Day (from Payment Terms: output the day number) and Payment Lag Months (from Payment Terms: output the number of months) — two computed columns that the AI derives during extraction — turn "末日締翌々月10日払い" into Settlement Day: 31 and Payment Lag Months: 2 (with payment on the 10th). A spreadsheet formula can then calculate the actual due date from the invoice date plus the settlement day plus the payment lag. The extraction step feeds the calendar the structured input it needs. The AP clerk no longer reads and parses. The AP clerk verifies.

This is not a workflow change. It is a data pipeline change — connecting the invoice PDF directly to the payment calendar by extracting the payment terms as structured data rather than as an opaque text string that a human must interpret. The same pipeline that feeds the payment calendar feeds the cash-flow forecast, the consumption tax period allocation, and the supplier payment-term audit. The calendar problem disappears not because the calendar got better but because the data feeding the calendar stopped being human-dependent.

The same principle — closing the gap between the document and the decision by extracting structured data — drives the batch invoice processing workflow, where thirty invoices produce one payment-ready spreadsheet with bank transfer details, withholding calculations, and payment schedule grouped by settlement day. And it mirrors the structural insight from the Australian BAS lodgement analysis: the form takes ninety seconds; the assembly takes days. In both cases, the visible deadline hides the invisible data assembly step, and the assembly step is exactly where the extraction layer closes the gap.

FAQ

Why can't the ERP system handle shimebi payment terms automatically?

ERP systems like NetSuite, SAP, and Oracle E-Business Suite do handle Japanese shimebi-based payment terms — but only after the terms have been entered into each supplier's master record. NetSuite's Japan Localization module, for example, allows you to define a closing date pattern and payment due date per supplier, and the system auto-calculates the payment due date for each transaction. The gap is getting the payment terms from the supplier's invoice PDF into the supplier master in the first place. When a new supplier sends their first invoice with payment terms "20日締翌月末払い," someone must read that text off the PDF and configure the ERP's closing date pattern accordingly. The ERP handles the ongoing calculation. It does not handle the initial extraction.

Do all Japanese companies use shimebi payment terms?

Most do for domestic B2B transactions. The system is deeply embedded in Japanese commercial practice. Some sectors — particularly large retailers dealing with many small suppliers — have begun shifting toward fixed-date payment (e.g., "payment on the 25th of the following month" regardless of individual billing cycles), but the shimebi convention remains the dominant model. For a mid-sized company receiving invoices from thirty suppliers, the realistic expectation is that twenty-five or more will use shimebi-based terms, and each supplier's terms may differ.

How does the Subcontract Act's 60-day limit interact with shimebi payment terms?

The Subcontract Act requires parent contractors to pay subcontractors within 60 days of receiving the goods or services. A parent contractor who negotiates payment terms of "末日締翌々月末払い" (end-of-month close, payment by end of month after next) with a subcontractor who delivers on the 1st of the month could face a payment window of approximately 60 to 90 days, depending on when the delivery falls relative to the billing cycle. This combination — a long shimebi lag plus the statutory 60-day limit — creates a compliance risk that requires active monitoring. The 14.6% late payment penalty under the Subcontract Act makes it the most expensive calendar error a company can make.

What happens when a supplier changes their payment terms mid-contract?

A supplier may change their payment terms at contract renewal or, in some cases, unilaterally by updating the terms printed on their invoices. If the AP team processes invoices using the old terms from the supplier master while the supplier has already switched to new terms, the payment calendar will be wrong for that supplier until the mismatch is discovered. This is most common with suppliers who switch from 翌月末払い to 翌々月払い to improve their own cash position — the AP team pays on the old (shorter) schedule, which is favorable to the supplier, so the supplier has no incentive to flag the discrepancy. The mismatch persists until an audit or a cash-flow anomaly draws attention to it.

The Calendar Problem Nobody Builds a Dashboard For

Payment calendar management in Japanese AP is a problem that does not generate its own dashboard because the symptom — a missed payment deadline — looks like a one-off error, not a systemic failure. The supplier sends a reminder. The AP team apologizes and processes the payment. The incident closes. The root cause — that the payment due date was never on the invoice as a date, only as a text string that a human had to parse, and the human parsed it wrong — does not appear in the incident report. It does not appear anywhere, because the data that would reveal it (the payment terms on the invoice vs. the due date in the spreadsheet) lives in two different systems, and no one compares them unless an error forces the comparison.

The gap is structural: the invoice carries payment terms in a format a computer cannot use (embedded text in a PDF). The AP team converts it into a format a computer can use (a calendar date in a spreadsheet) through a step that is entirely dependent on human attention — reading, parsing, typing. Across thirty suppliers, thirty invoices per month, twelve months per year, this step happens 360 times. The error rate is low in percentage terms and costly in absolute terms because each error cascades into supplier relations, cash-flow forecasts, tax filings, and compliance exposure. The fix is not a better calendar. The fix is closing the gap — making the extraction step produce structured payment terms data that a calendar can consume directly, so the calendar is derived from the invoice rather than from a human's reading of the invoice.