Internal-Rules Revision: Versioned and Approved Compliance

A factory has a binder. Inside is the approval regulation, the document that says who can sign off on a 1-million-yen purchase, who must countersign a 5-million-yen one, and which director signs a capital expenditure. The binder has been photocopied, annotated by hand, and re-copied so many times that nobody is sure which page is the current rule and which is a draft someone forgot to remove. When the auditor asks which version of the approval regulation was in force when a disputed payment cleared, the answer is a shrug.

This is the governance gap most mid-size Japanese manufacturers do not see until a review forces them to look. The company has internal rules. It even revises them. What it lacks is a versioned, approved record of those revisions. Every policy change floats in email, a shared drive, or a binder nobody dares throw away. Compliance audits fail not because the rules are wrong, but because nobody can prove which version was in force when. The fix is to treat internal-rules revision as its own approval workflow, inside the core business system that runs every other request.

Why Policy Governance Fails the Audit

Internal rules and the approval regulation itself (the ringi regulation that defines who can approve what) are the foundation of every other control. When that foundation has no governed change process, the controls built on top of it stop being defensible. This is where an ERP earns its place, by governing rule changes as strictly as it governs transactions.

The failure shows up in three places. First, no version trail. A rule is changed by emailing a new PDF and asking everyone to use it. Six months later, three versions exist in three inboxes, and nobody knows which one governed a specific transaction. Second, no approval evidence for the change itself. Someone revised the approval threshold from 2 million yen to 5 million yen, but there is no record of who approved that revision or when it took effect. Third, no restoration path. When a revised rule turns out wrong, the company cannot cleanly roll back, because the prior version was overwritten the moment the new one circulated.

The irony is sharp. Companies that spend weeks reconstructing transaction-level approval evidence for a J-SOX review often have zero evidence for the policy that defined those approval rules in the first place. The internal-control reviewer notices. The 2024 J-SOX revision, effective for fiscal years beginning on or after April 1, 2024, expects evidence over assertion at every layer, including the policy layer. A core business system that versions and approves rule revisions closes that gap.

A Scenario: The Precision Parts Maker in Shizuoka

Picture a precision parts manufacturer in Shizuoka, about 280 staff, supplying stamped components to automotive tier-one OEMs across the country. The company has a thick approval regulation, last formally revised four years ago. Since then, the business has changed: new product lines, a second factory, a reorganized purchasing department, and a new executive team.

In the as-is state, policy changes happen by email. The general affairs lead drafts a revised section, attaches it to a message, and asks the executives to reply with agreement. Some reply, some do not. A few reply weeks later. The final, approved version is whatever the lead assembled from the replies, saved to a shared folder with a filename like "approval_regulation_v_FINAL_v3_use_this.xlsx." When an internal-control reviewer asks to see the version that was in force during the previous fiscal year, the team spends two days hunting through folders, trying to explain why three files all claim to be the current version.

The deeper problem is the change itself. The threshold for executive sign-off on a purchase order was raised from 3 million yen to 8 million yen at some point during the year. Nobody can say exactly when it took effect, because the change was never formally approved, dated, or versioned. A 6-million-yen PO that cleared mid-year sits in a gray zone. Under the old rule it required executive approval. Under the new rule it did not. Which rule governed determines whether the segregation-of-duties test passes or fails.

What a Versioned Rules-Revision Workflow Actually Does

Moving internal-rules revision into the same ERP that runs every other request changes the starting point. Instead of reconstructing the policy trail after the fact, the system captures it as the revision happens. Reading the actual workflow engine, here is what is genuinely built.

Every revision is an approval request, not an email

A rule revision starts life as a structured request, the same kind of request the company uses for expense claims, purchase orders, and leave. The requester attaches the revised document, describes what changed, and submits. The ERP routes the revision to the right approvers based on the rules the company defines. For a change to the approval regulation itself, that might mean the full executive committee. For a department-level procedure, it might mean the department head plus the compliance officer.

Because the revision is an approval request, it inherits everything the workflow engine already does. The route can require a committee quorum (3 of 5 executives must agree) or any-of-N approvers for speed. The route can land on a position rather than a named person, so a revision proposed during an executive reshuffle does not stall. Watchers can follow the revision without being approvers, so the internal audit team observes every policy change without blocking it. None of this is bolted on. It is the same engine running the company's other workflows.

A frozen snapshot of exactly what was approved

This is the capability that makes policy governance auditable. When the revision is submitted, the system takes a snapshot of the document and the form data, and versions it. The approvers are not approving a live file that could be edited underneath them. They are approving a fixed, time-stamped picture of the revised rule. When an auditor asks, six months later, what the approval regulation said on the day it was revised, the answer is a single versioned record.

Every action on that revision writes a line into the request's audit entries. Who proposed it, who reviewed it, who approved or rejected it, when each step happened, and what the service-level deadline was. Even an administrator forcing a stalled revision through is itself recorded, with the admin's identity and the reason captured. If someone overrides the normal chain, that override is part of the trail.

Full version history, restorable on demand

Because each revision is versioned at approval, the company builds a complete history of every policy change over time. Version 7, version 8, version 9, each with its approval chain, its effective date, and its full document snapshot. When a revised rule turns out to be wrong, the company does not have to scramble. The prior version is right there, with its own approval evidence, ready to be reinstated through the same governed workflow.

This is what compliance reviewers actually want to see. Not a binder of photocopied pages, but a queryable record of every policy change: who proposed it, who approved it, when it took effect, and exactly what the rule said at every point in time. The version history is the policy-change trail that an email-and-binder process can never produce.

The Japan Context: Why This Matters More Now

Japan sharpens the stakes on policy governance in two ways. First, the J-SOX revision that took effect for fiscal years beginning on or after April 1, 2024 raised the bar for internal-control evidence. The standard now expects a demonstrable, versioned record of the controls themselves, not just the transactions that flow through them. A company that cannot show which version of its approval regulation governed a disputed payment has a control-design finding, not just a documentation gap.

Second, the labor shortage that 48.7 percent of Japanese companies now cite as their top barrier to digitalization (per the 2025 White Paper on Information and Communications) makes tacit policy knowledge dangerous. When the one person who "knows the real rules" retires, the binder becomes unreadable. A core business system that captures every policy revision as an approved, versioned record transfers cleanly to the next generation.

The qualified-invoice system adds a third layer. Since October 2023, every taxable purchase must tie back to a real approval under a real rule. A consumption-tax deduction defended by "this was within the approval threshold" is only as strong as the versioned record of what that threshold was on the day of the purchase. The policy trail and the transaction trail are one control.

The Honest Limits: What Is Manual Today

A responsible post names what the system does not do yet, because overselling governance is itself a control weakness.

The versioned rules-revision workflow captures the approval chain, the document snapshot, and the full history beautifully. It does not, on its own, auto-enforce the revised rule against live transactions the moment it takes effect. If a revision raises the purchase-order threshold from 3 million yen to 8 million yen, the routing rule for new purchase orders is a separate configuration step. The system records that the policy changed and when. Turning that changed policy into live routing thresholds is a governed configuration action, done by an administrator whose action is itself logged. For companies that want the revised rule to auto-propagate into every downstream workflow without any human step, treat that as a roadmap conversation.

A second honest limit, shared across the whole workflow engine. The approval workflow records decisions and versions documents, but it does not automatically write every operational event into the accounting ledger. Only expense reimbursements and leave applications generate records automatically on approval today. Policy revisions do not touch the ledger, and they do not need to. But it is worth saying plainly: this is a governance and versioning capability, not a financial-posting one. Naming that boundary matters more than blurring it.

Frequently Asked Questions

Our internal rules are not that complicated, do we really need a revision workflow?

The simpler the rule, the harder it is to defend a messy change process. A two-page approval regulation revised by email, with three competing versions in circulation, is harder to audit than a hundred-page regulation with a clean version history. Complexity is not the trigger. The existence of any revision lacking an approval chain and an effective date is the trigger, so if your rules have ever changed, you need this.

How is this different from a document management system?

A document management system stores files and maybe versions them, but it does not run an approval workflow with committee quorum, position-based routing, watchers, and a frozen snapshot of what each approver saw. The difference is the decision layer. Versioning a file is storage, while versioning a file plus the governed approval that authorized the change is policy governance. A core business system does the second because the approval engine is the same one running every other request in the company.

Will moving rule revisions into the system break our current process?

No. The right way to migrate is to import your current, in-force rules as the baseline version, then run every future revision through the workflow. You do not need to reconstruct years of history retroactively, you just establish the clean versioned record going forward. From that point on, every change is captured, and the first audit cycle after adoption is where the value shows up.

Can we keep using email for minor rule tweaks?

You can, but the same logic that sank your transaction approvals applies to your policy approvals. An email tweak is an unversioned, unapproved change an auditor cannot trace. The cost of pushing even a minor revision through Kikan System is a few minutes, and you can start on the free plan with up to 2 users and no credit card. For anything that affects segregation of duties, approval thresholds, or financial controls, route it through the system without exception.

Key Takeaway

Internal rules and the approval regulation are the foundation of every other control. When that foundation has no governed, versioned change process, the controls built on top of it stop being defensible. A core business system that treats every rule revision as an approved, versioned request, with a frozen snapshot and a full audit trail, gives the company what an email-and-binder process never can: a provable record of which version of every rule was in force, when, and who authorized the change.

Get Started With Kikan System

If your approval regulation lives in a binder of photocopied pages and your last revision is buried in an email thread, look at Kikan System. The workflow engine runs rule revisions through the same governed approval process as every other request, with version history, frozen snapshots, committee quorum, and a full audit trail. You can start on the free plan with up to 2 users, no credit card required. Begin at /#get-started.