Stop Double Payments: Payment-Execution Approval

It is the 27th of the month. The accounting team at a precision parts maker in Shizuoka, about 280 staff, supplying automotive OEMs, is clearing the month-end payment batch. A clerk selects a stack of vendor bills, clicks pay, and the bank transfers begin. Later that afternoon, the same supplier calls about a different invoice. The clerk pulls it up, sees it was already marked paid, and pays it again to be safe. Nobody catches it until the supplier reconciliation two months later. The duplicate, 1.8 million yen, is already gone.

That scene does not require negligence. It requires only manual payment execution with no control gate before funds actually move. A core business system fixes the root cause: payments never leave the company until an independent approver has confirmed the amount, the vendor, and that it has not been paid before. This post explains the payment-execution approval workflow that protects cash, what the audit trail captures, and where the honest boundary is today between the control that is built and the automatic bank execution that is still on the roadmap.

Why Double Payments and Wrong Payments Are a Cash-Protection Problem

Duplicate and erroneous payments rarely make the news, but they are one of the largest avoidable losses inside a back office. The cost is not the single mistake. It is that the mistake is invisible. A supplier overpaid once will rarely call to return the money. A payment sent to the wrong vendor may sit unrecovered for months while legal and bank-reversal fees pile up.

Three conditions make the loss almost inevitable on paper. First, there is no segregation of duties. The same person who decides to pay, who keys the bank transfer, and who records the entry can do all three without anyone else looking. Second, there is no frozen record of what was approved. An email saying "approved" can be edited, deleted, or sent to the wrong thread. Third, there is no system check against prior payments. The clerk relies on memory or a spreadsheet that may or may not be current.

A core business system removes all three at once. The person who releases funds cannot be the person who created the payment batch. Every approval is frozen with a timestamp, the approver, and the exact amounts. The system refuses to pay any bill twice because it tracks what has already been released.

What a Payment-Execution Approval Workflow Actually Does

This is not about scanning a bill and hoping it gets paid correctly. A real payment-execution approval workflow inside an ERP gates the release of cash behind a configurable, multi-step sign-off that must clear before anything moves. Reading the workflow engine, here is what is genuinely built today and what is honestly still on the roadmap.

Multi-step sign-off that matches your authority rules

A payment batch does not go out the moment a clerk finishes it. The workflow binds the batch to a defined approval route, and the status flows through draft, submitted, and approved before a single yen can move. For a routine batch of small bills, one manager clearance may be enough. For a large payment to a new vendor, the route can require two or three independent approvals, each from a different role.

The routing is not hard-coded to a name. Approvals route to the role, the position, or the department, so they survive reorganizations and staff changes. A controller who leaves does not break the workflow, because the next person in that position inherits the approval authority automatically. This makes the control durable, not dependent on one person's habits.

Segregation of duties that cannot be bypassed

The single most important control in payment execution is that the person who prepares a payment cannot also approve it. The workflow engine enforces this by construction. The preparer submits the batch, and the approver is a different person at a different step. There is no shortcut where one staff member both creates and releases funds.

For larger or riskier payments, the route can require committee sign-off. A threshold rule can demand that, of five approvers, at least three must clear before the payment is released. This prevents a single person from pushing a large, unusual, or fraudulent payment through on their own. It is the same structure auditors look for under J-SOX and internal-control reviews, built into the flow, not bolted on after the fact.

See exactly where every payment is stuck

A payment batch that sits in someone's inbox for a week may miss its early-pay discount or breach its due date. The workflow shows exactly where every request is stuck, at which step, and with whom. A stakeholder who needs the payment to move can watch it without being an approver.

Approvals also do not freeze when a manager travels. The workflow supports safe delegation, where a traveling approver hands off clearance to a deputy, with mandatory re-approval for high-risk items on return. Business-day SLA deadlines keep the payment moving instead of stalling behind a single absent signer.

A frozen snapshot of exactly what was approved

This is the audit trail that makes the control defensible. When an approver clears a payment batch, the workflow freezes a snapshot of exactly what was approved: the bills, the amounts, the vendors, and the totals. That snapshot cannot be edited later. If someone changes a bill after approval, the system records the change and can require a fresh approval before the payment moves.

For any future question, whether internal, from a board, or from an external auditor, the answer is already there. Who approved the payment, when, against which version of the bills, and with what authority. A paper stamp book cannot answer those questions. A frozen approval snapshot answers all of them, immediately.

Where the Honest Boundary Is Today

This is the part that matters most, because overselling cash controls is dangerous. The payment-execution approval workflow, the multi-step sign-off, the segregation of duties, and the frozen audit trail are all built and live today. The control gate that must clear before a payment is released is real and in production.

What is not built yet is automatic execution of the payment in the bank or payment system. When approval completes, the workflow confirms the payment is cleared to move. It does not, on its own, push the transfer file to the bank or hit the payment gateway. That writeback is on the roadmap. Today a cleared approval tells your team the control has passed and the payment is safe to release. The actual bank transfer is still confirmed by your finance team, which is exactly the segregation of duties you want.

Being precise about this boundary is the point. You get the control that prevents the duplicate, the audit trail that proves who approved what, and the segregation of duties no single person can bypass. You do not yet get hands-off automatic bank execution, and you should not be promised it.

A Scenario: The Precision Parts Maker in Shizuoka

Consider a precision parts manufacturer in Shizuoka, about 280 staff, supplying automotive and industrial-machinery OEMs. Every month, the accounting team clears roughly 600 vendor bills worth about 320 million yen in aggregate. Before their core business system, payment execution ran like this: a clerk built a payment list in a spreadsheet, a manager glanced at the total and replied "ok" by email, and the clerk keyed the bank transfers one by one.

The failure modes were predictable. The same invoice was sometimes paid twice when a supplier called and the clerk could not recall whether it had been released. A payment occasionally went to the wrong vendor when a bank account was copy-pasted from an old row. And when the external accountant asked, mid-audit, who had approved a particular 4.2-million-yen payment, nobody could answer with certainty. The approval had been a one-line email, later deleted.

In the new flow, the accounting team builds the payment batch in the ERP, bound to an approval workflow before it can move. For batches above a threshold, the route requires two independent approvals from different roles, and the preparer is structurally barred from being one of them. The approver sees the full list of bills, vendors, and amounts, frozen as a snapshot the moment they clear it. The system refuses to release any bill that has already been paid, so a duplicate is impossible by construction, not by memory. When the external accountant asks who approved that 4.2-million-yen payment, the answer is a timestamped record with the approver, the authority, and the exact version of the bills approved.

The actual bank transfer is still confirmed by the finance team when the approval clears, because automatic payment execution is on the roadmap. The control that stops the duplicate and the wrong payment is the approval gate, and that gate is live.

Why This Matters Beyond Saving Time

The benefit is not only avoided losses, though those losses are real and can run into millions of yen per incident. A 2024 TOKIUM survey found that 90.4 percent of employees still submit paper receipts and only 7.0 percent of expense claims are fully electronic. That same paper reliance extends to payment execution in most mid-size companies. When the payment list lives in a spreadsheet and the approval lives in an email, the control is whatever the last clerk remembered to check.

There is also an internal-control angle. Segregation of duties between payment preparation and approval is one of the first things a J-SOX or internal-control reviewer tests. A frozen approval snapshot, with role-based routing and a versioned record of exactly what was cleared, is the evidence that passes that test without a scramble. You built the control into the payment flow from the start.

Finally, there is succession planning. Many Japanese mid-size manufacturers carry the entire payment process in the head of one veteran accounting person, including the informal rule about which bills need a second signature. When that person retires, the control retires with them. A core business system captures the routing, thresholds, and audit trail so the next generation inherits a controlled process, not a set of habits.

Frequently Asked Questions

If the system does not push the bank transfer automatically, what does the approval actually do?

It does the part that matters most for preventing loss. The approval gate confirms that the right people have reviewed the amount, the vendor, and the payment list before any funds can move. It enforces segregation of duties and freezes an audit trail. Automatic bank execution removes keystrokes but does not add control. The control is the approval, and that is built today.

Can we require a second approval only for large payments?

Yes, and this is where threshold routing earns its keep. A routine batch of small bills may need one manager clearance. A batch above a set amount, or a large payment to a new vendor, can require two or three independent approvals, or a committee sign-off where at least three of five must clear. The threshold and routing travel with the workflow rule, not with whoever happens to be at the desk.

How does the system stop a duplicate payment if the same bill is submitted twice?

By tracking what has already been approved and released. When a bill enters a payment batch, the workflow knows whether it was already part of a cleared payment. A clerk who tries to add it again is blocked before the batch is submitted. The duplicate is prevented by the system, not by a person remembering.

What happens if an approver changes a bill after clearing it?

The frozen snapshot records exactly what was approved at clearance. If a bill is changed afterward, the workflow records the change and can require a fresh approval before the payment moves. The audit trail always reflects the version actually approved, so there is no gap between what was signed off and what was paid.

Key Takeaway

Stopping double payments is not a matter of diligence. It is a matter of a control gate that must clear before funds move. A core business system puts every payment behind multi-step approval, enforces segregation of duties between preparer and approver, and freezes a snapshot of exactly what was cleared. The approval control is built and live today. Automatic payment execution in the bank is on the roadmap, and that is exactly the right order, because the control is what protects the cash.

Get Started With Kikan System

If duplicate payments and wrong-vendor transfers keep you up at month-end, look at Kikan System. The payment-execution approval workflow gates every payment behind multi-step sign-off and segregation of duties, with a frozen audit trail of who approved what. You can start on the free plan with up to 2 users, no credit card required. Begin at /#get-started.