One System for Expenses, Ringi and Leave: Cut Tool Costs and Double Data Entry

A mid-size industrial machinery maker in Nagoya, about 180 staff, runs its expense claims on one cloud tool, its ringi (internal approval proposals) on a second, and its paid leave on a third. Tucked behind those sit shared spreadsheets for travel advances and a busy approval inbox. A line worker asking for a day off logs into the leave tool. The same person, back from a client trip, logs into the expense tool. A manager approving a capital request logs into the ringi tool. Five systems, five logins, five monthly invoices, and the same names typed into each one. The finance lead then copies approved amounts from the expense tool into the accounting software by hand, because nothing talks to anything else.

This sprawl is the quiet tax of buying best-of-breed point tools. Each one looked affordable in isolation. Together they cost more than a single core business system, and they still leave the company without one trustworthy view of who approved what. The fix is not a sixth tool that promises to connect the other five. The fix is to consolidate every request type into one ERP.

Why Five Tools Cost More Than One

Subscription sprawl hides its true cost. Each approval tool bills per seat, per month, forever. Add the integrations, the single sign-on connector, the annual renewal premium, and the half-day each quarter someone spends reconciling which seats are still used. For a 180-person company, four approval point tools can easily run between 3 million and 5 million yen a year before anyone files a single request.

The bigger cost is invisible. Because each tool stores its own copy of the employee, the department, the project, and the approval rule, staff end up entering the same data two, three, or four times. A sales engineer files a travel expense in the expense tool, then re-enters the trip into the timesheet tool, then emails a separate travel advance request to finance. When an employee transfers departments, someone has to update their routing in every tool individually, and one is always missed.

The market data backs this up. According to atled research, 67.7 percent of Japanese companies already use a workflow system, yet roughly 28 percent still run none at all. Among those that did adopt a tool, a SIOS 2025 survey found that about 40 percent are stuck at what it calls electronified paper. They scanned the old ringi form into a new app but kept every silo intact. Adoption without consolidation is the most expensive outcome of all. You pay the software bill and still do the manual work.

One System, Many Request Types, Each With Its Own Form

The core idea behind a unified core business system is that the request type changes, but the engine does not. An expense claim, a ringi proposal, and a paid leave application are all just structured requests that need someone to approve them. The system lets you define a distinct form for each, with only the fields that request needs, and no developer involvement.

An expense form can carry line items with tax breakdowns and receipt attachments, plus a receipt-required rule per cost category. A leave form can carry the leave type, the dates, the remaining balance, and an attached reason. A ringi form for a capital investment can carry the amount, the payback period, the expected return, and supporting documents. Each form is built from configurable field types, and fields can show or hide based on what the requester entered, so a domestic travel request never asks for a passport number and an international one always does.

This is the difference between a single system and a collection of apps. In a single ERP, every form draws from the same master records. The requester, the department, the project code, and the cost center are all live references, not free text typed into five different boxes. Change the department once and every pending request across every form type picks up the new routing.

Unified Approvals That Survive Reorganizations

Once every request type lives in one system, approvals unify naturally. The same approval engine handles an expense claim, a ringi, and a leave application. Routing goes to the role, the position, or the department, not to a named person. When the company reorganizes and the Sales Department splits into two sections, the routing updates with the org change instead of breaking it.

Big spend can require more than one pair of eyes. A capital request above a threshold can require a committee sign-off with a quorum, so three of five directors must approve before a large purchase moves. For faster, lower-risk requests, any-of-N routing lets the first available manager in a group approve, so a request never waits just because the primary approver is on leave that afternoon. Routing can also follow the requester, sending each request to that person's own manager automatically. You stop maintaining a routing table per request type because there is one routing concept, applied consistently.

This is exactly the gap the SIOS data exposes. The 40 percent stuck at electronified paper scanned the form but kept approval as a serial email chain. Unified approvals close that gap by making the decision path part of the data, not a side conversation in someone's inbox.

See Where Every Request Is Stuck, in One Place

Fragmented tools make status chasing a full-time job. In the five-tool world, a manager who wants to know what is waiting opens the expense tool, then the ringi tool, then the leave tool, then email, then a spreadsheet. An employee asking whether their leave was approved has to remember which system they filed it in.

One ERP collapses this into a single queue. Every pending request, across every form type, is visible in one place. You can see exactly where each request is stuck, who it is waiting on, and how long it has been there. Business-day service level deadlines make slow approvals visible rather than invisible. Watchers let a stakeholder follow a request without being an approver, so a project lead can track a capital decision that affects their timeline without inserting themselves into the approval chain.

When a manager travels, approvals do not freeze. Safe delegation lets them hand off their queue, with mandatory re-approval for high-risk items so a delegate cannot quietly sign off on something they should not. This is the single biggest reason fragmented ringi tools stall in Japan. The decision waits for a physical return. Unified delegation removes the wait without removing the control.

One Audit Trail Instead of Five

Internal control and J-SOX readiness live or die on the audit trail. Five tools mean five places to look during a review, five export formats, five sets of timestamps that may or may not agree. When an auditor asks who approved a specific capital purchase and when, the answer is often a screenshot from one tool, a forwarded email, and a hope that the dates line up.

A core business system keeps one frozen snapshot of exactly what was approved, by whom, and at what timestamp, across every request type. The expense claim, the ringi decision, and the leave approval all live in the same history. You query one system and get one answer. For a manufacturer facing internal control review, this is the difference between a clean audit and weeks of reconstruction.

A Scenario: The Industrial Machinery Maker in Nagoya

Return to the company in Nagoya. Before consolidation, an engineer requesting a client visit had to open the leave tool to book the day, the expense tool to file an advance, the ringi tool if the trip crossed a cost threshold, and email the manager in between. Four logins for one trip.

In the consolidated model, the engineer opens the single ERP. A travel request form collects the dates, the destination, and the estimated cost in one submission. The form knows the engineer's department and routes to their own manager automatically. If the estimated cost crosses the threshold, the same request adds a ringi step with a committee quorum, no separate tool opened. When the trip ends, the engineer files the actual expense against the same request, attaching receipts to each line, and the leave balance updates against the same record. The manager sees one thread, not four. Finance sees one approved amount and one audit trail, with no re-entry.

At month-end, the accounting lead no longer exports from three tools and pastes into the books. Approved expense reimbursements and leave applications write through in the system. The company retires two of its four approval tool subscriptions in the first quarter and renegotiates the rest, and the manual cross-entry work that used to eat the finance team's month-end simply stops existing.

Being Honest About What Writes Back Automatically

A unified ERP does the approval work for every request type from day one, but automatic write-back to accounting records is built for only two today. When an expense reimbursement is approved, the system writes the journal entry automatically. When a leave application is approved, the balance updates automatically. For purchase orders, vendor records, bills, and invoices, the approval flow is built now and the automatic record creation is on the roadmap. That is the honest line. You get one approval system for every request type immediately. You get automatic accounting entries for expenses and leave now, and the rest as the roadmap lands.

This matters because overselling write-back is how companies end up disappointed in digital transformation projects. A vendor that promises every approval posts every journal on day one is either mistaken or counting on you not to check. The right expectation is that consolidation of the request and approval layer is the immediate win, and the automatic accounting layer grows request type by request type from there.

Common Questions About Consolidation

Will we lose the workflows we already built in our current tools?

You rebuild them, but faster than you expect. Because each form is configurable without a developer, recreating an existing expense or leave flow is an afternoon, not a project. The bigger value is that you can finally align the fields and rules across request types, so the department list and the project codes match everywhere instead of drifting between tools.

What happens to approvals when a manager is out of the office?

Unified delegation handles this. A manager can delegate their queue for the days they are away, and high-risk items can be configured to require re-approval by the original manager on return. Approvals no longer stall for a week because someone is at a supplier visit.

How does this reduce double data entry?

Because every request type reads from the same master records. The requester, the department, the project, and the cost center are entered once and referenced everywhere. An employee transfers departments, and every pending request across every form picks up the new routing without a human updating five tools.

Is this only for large enterprises?

No. The workflow engine can be deployed standalone first, without the rest of the ERP, which makes it practical for a mid-size company that wants to consolidate approvals before touching accounting. Prove the consolidation ROI on expenses, ringi, and leave, then connect the rest of the system as you grow.

Key Takeaway

Running expenses on one tool, ringi on another, and leave on a third is the most expensive way to do the cheapest part of operations. A single core business system handles every request type with its own form, routes approvals by role so they survive reorganizations, and keeps one audit trail instead of five. Consolidation is not about buying more software. It is about buying less, once, and getting one trustworthy answer to who approved what.

Get Started With Kikan System

If you are paying for four approval tools and still chasing status across all of them, look at Kikan System. One system runs expenses, ringi, and leave, each with its own configurable form, with unified approvals and a single audit trail. You can start on the free plan with up to 2 users, no credit card required. Begin at /#get-started.