Link Accounts Receivable Collection to Payment Schedules

It is the morning of the 25th. The accounting lead at a precision parts maker in Higashi-Osaka opens a spreadsheet titled "unpaid" and starts scrolling. About seventy staff, two hundred active customers, and the list of open invoices is growing. She knows roughly who is late, but she cannot tell at a glance which invoices crossed their due date this week, which payment terms each customer is on, or how much is "actually overdue" versus "not due yet." So she emails sales, sales emails back a guess, and the cash that was supposed to land before month-end arrives two weeks late.

That scene plays out in finance teams across Japan every month. The problem is rarely laziness. It is that the receivable, the payment terms, the due date, and the collection effort live in different places. A core business system fixes this by putting them on the same record, so collection follows the schedule instead of chasing a feeling.

Why collection has to follow the schedule, not the calendar

The number that should drive collection is not "how old is this invoice." It is "how many days past its contracted due date is this invoice." Those sound similar, but they are not.

A customer on end-of-next-month terms who was invoiced on the 3rd is not late on the 20th. A customer on 30-day terms who was invoiced on the 3rd is very late by the 20th. If your team treats both the same, you either harass a good customer who is perfectly on schedule, or you miss the one who is genuinely overdue. Both erode trust and both cost money.

The fix is structural. The receivable has to carry the schedule that produced it. When you confirm an invoice, the system should read that customer's payment terms, calculate the due date, and stamp it on the document. From that moment, every report, every aging bucket, and every reminder can be ordered by distance from a real due date rather than from an issue date.

This is not a nice-to-have. Late payments hit about 49 percent of business-to-business transactions in Japan, and average payment terms run about 42 days from invoicing, according to Atradius' 2025 Payment Practices Barometer for Japan. When half your receivables are at risk of slipping, you cannot afford to collect blind.

The schedule is the source of truth

In a well-built ERP, the payment schedule is a first-class record, not a free-text note. You define a payment term once, then attach it to each customer. The term carries two things: how the due date is derived, and how the due amount is calculated.

For the date, the system supports the patterns Japanese finance teams actually use. End-of-month, where the invoice falls due on the last day of the issue month. End-of-next-month, the close-the-books-friendly term many trading companies prefer. A fixed day of the next month, such as "the 15th of the following month," common for repeat wholesale accounts. And days-after-invoice, the plain net term service businesses use.

For the amount, the term can be a percentage of the invoice total or a flat amount. That matters when you bill a customer in installments, or when a contract specifies a partial advance and a balance on delivery. The schedule encodes the agreement, and the receivable inherits it. Nobody has to remember.

When a sales invoice is confirmed, two things happen at the same time. The system assigns the invoice number, and it computes the due date from the customer's attached payment term. The two are linked for the life of the document. If you reopen the draft and reconfirm, the same number is reused and the due date is recalculated against the current invoice date. There is no separate "terms" field that drifts out of sync with the real due date, because there is no separate terms field. The due date is the terms, made concrete.

Reading the receivable the way a collector needs to

Once the due date is real, the aging view becomes honest. You can sort open invoices by days past due instead of by days past issue. You can build the three views a collection team actually uses.

The first is "due soon." These invoices are inside their terms, but the due date is close. A gentle reminder here protects the relationship and prevents the slip in the first place.

The second is "genuinely overdue." These are past their contracted due date and now represent real collection work. This is where phone calls, escalation, and approval workflows earn their place.

The third is "disputed or held." Sometimes a customer has a reason. The goods arrived late, the consumption tax line does not match the qualified invoice registration number on file, the lot was rejected and a credit memo is pending. You need to see that a receivable is on hold and why, instead of hammering a customer for a bill genuinely in dispute.

A double-entry core business system makes the third view possible because credit notes are real documents, not edits. When a credit memo is issued against a prior invoice, it inverts the receivable effect cleanly. The collector can see that an offsetting credit exists and adjust the chase accordingly.

One company, one schedule, one number

Take a precision parts maker in Higashi-Osaka, about seventy staff. They sell fixtures to construction traders and to a handful of equipment assemblers, mostly on end-of-next-month terms, with their two largest customers on a fixed-15th-of-next-month arrangement that their sales director negotiated years ago.

Before, the accounting team maintained a running spreadsheet. Each invoice was a row, and the "due" column was filled in by hand based on a memory of that customer's terms. Mistakes were routine. The two large customers sometimes got a reminder before their terms allowed, which annoyed a purchasing manager who controlled a meaningful share of revenue. Smaller customers sometimes went unchased for 45 days because nobody realized their 30-day window had closed.

After the receivable is tied to the schedule, the picture changes. Every invoice carries a due date computed from the customer's real term. The end-of-month customers are grouped and chased together in the last week of the month. The two large customers are excluded from reminders until after the 15th. Disputed lines are flagged because the credit memo exists in the same system, not in an email thread.

For a company of this size, the gain is not a dramatic percentage. It is steadiness. Cash arrives when the terms say it should, the big customers stop getting mistaken reminders, and the accounting lead stops the month rebuilding a spreadsheet by hand. Across a year, the difference between "collecting by memory" and "collecting by schedule" is several weeks of working capital, which for a seventy-person maker is the difference between a comfortable month-end close and a scramble to meet payroll.

What gets automated, and what stays human

Honesty about automation matters, especially in finance. Here is what the system does for you, and where a person still has to decide.

The system computes the due date from the payment term at confirmation. It assigns the invoice number. It posts the accounting journals when an invoice is confirmed, so the receivable lands in the ledger at the same moment it lands on the customer. It records who confirmed the document and when, so there is a trail. It lets you split a received payment across methods, so a customer who pays part by bank transfer and part by cash is recorded correctly, with the bank and reference captured for reconciliation. It blocks deletion of a paid document, so settled history cannot be quietly erased.

What it does not do is auto-chase. There is no system that sends a dunning email sequence on its own, because in Japan a wrong reminder to a senior customer is worse than no reminder. The collector decides when and how to follow up, working from a list that is already correctly ordered by real overdue days. The schedule gives you the targets. A person still does the relationship work of collecting.

And to be plain about the boundaries: collections in this system are not multi-currency. If you bill overseas customers in dollars or euros and need exchange-rate conversion on the receivable, that is not built today, and you would handle the conversion manually until it is on the roadmap. Cash application against a specific invoice line is also a judgment call a person makes when a customer pays a partial amount or bundles several invoices into one transfer. The system records the payment against the partner; mapping it precisely to invoices is the collector's expertise.

The Japan context that makes this urgent

Two forces make payment-schedule discipline more important now than it was five years ago.

The first is the 2025 legacy cliff. Many Japanese companies are running older finance platforms that the original vendor no longer supports, and finance teams are being forced onto new systems as the old ones age out. That disruption is also an opportunity. When you move, you can stop carrying forward the bad habit of hand-maintained due dates. You can build the schedule into the receivable from day one in the new system.

The second is the cash pressure itself. Teikoku Databank reported 10,261 corporate bankruptcies in Japan in 2024, the first time the count crossed 10,000 in 12 years, driven largely by small-scale businesses squeezed by rising costs and the labor shortage. When margins are thin and bankruptcy risk is elevated, the difference between collecting on day 35 and day 65 is not a rounding error. It is survivability. A company whose largest customer pays 30 days late because nobody noticed is financing that customer's working capital for free, and in 2025 that is a luxury many small makers cannot afford.

The qualified invoice system adds a third layer. Since the rollout of the registration requirement, customers have become stricter about matching the registration number and the consumption tax lines on an invoice before they release payment. A receivable that is tied to a clean, confirmed document, with the tax breakdown and registration number correct at confirmation, clears payment faster than a paper invoice with a handwritten correction. Schedule discipline and document discipline reinforce each other.

Tying it back to real modules

None of this is abstract. The payment term is a master record you define once and reuse across customers, with a default enforced so new invoices always inherit sensible terms even when someone forgets to set them. The invoice confirms against that term and stamps the due date, then moves to CONFIRMED, SENT, and PAID through a lifecycle that locks the underlying sales document the moment the receivable is created. Payments record the cash received, split by method, against the partner, with a status that moves from draft through in-progress to paid. Credit notes invert the receivable cleanly so disputes and returns are visible to the collector, not buried.

For Japanese customers on running-balance billing, the invoice can carry a balance-forward style, where the prior balance, payments received, and the carried-forward amount all appear on the statement. That is the format many wholesale and trading customers expect, and it means the collector and the customer are looking at the same running number when they discuss what is owed. Every company keeps its data fully isolated, so the customer master, the payment terms, and the receivables of one entity never bleed into another.

Frequently Asked Questions

Will switching systems make collections worse before they get better?

Any migration has a learning curve. The way to keep collection steady is to load every customer's correct payment term into the new system before you go live, so the first invoices you confirm already carry the right due date. If the terms are clean on day one, the aging view is honest on day one. The risk is not the software, it is loading stale or wrong terms and then trusting the new due dates.

How long until this pays for itself?

For a company of seventy staff with a few hundred customers, the payback usually shows up within two or three month-end cycles. You stop chasing customers who are inside their terms, you stop missing customers who slipped, and you reclaim days of working capital each month. The exact figure depends on your average invoice size and your current overdue rate, but if late payments touch even 20 percent of your receivables, the schedule correction typically covers its own cost quickly.

Does this handle the billing conventions wholesale and trading customers expect?

Yes. End-of-month, end-of-next-month, fixed day of next month, and net-days terms are all supported natively, and the balance-forward statement style matches what many wholesale and trading customers expect. Consumption tax lines and the qualified invoice registration number are captured on the confirmed invoice, which is what customers now check before releasing payment.

Can a small finance team actually use this, or is it built for large companies?

It is built so a small team can act like a larger one. The collector opens a list already sorted by real overdue days, sees disputed credits alongside open invoices, and works top to bottom. You need one person and an honest schedule, not a dedicated credit-control department, and the free plan in Kikan System supports up to 2 users with no credit card required.

Does the system send dunning emails automatically?

No, and that is deliberate. A wrong reminder to a long-standing customer is worse than no reminder, so the collector decides when and how to follow up. The system gives you a list already correctly ordered by real overdue days, and a person still does the relationship work of collecting.

Start collecting by schedule

If your team is still scrolling a spreadsheet titled "unpaid" on the 25th, the schedule is already broken. Fix it once, in a system that computes the due date from real terms and shows you overdue as overdue.

Kikan System ties each receivable to its payment schedule, computes the due date at confirmation, and gives your collector a list ordered by real overdue days. Start free with up to 2 users, no credit card required, and confirm your first invoice on a real schedule today. Get started or compare plans at pricing.