Key Takeaways

• Close tools that genuinely support policy-based approvals block self-approval and hold every journal until it is approved; recording the approval is not enough.

• A complete audit trail is built as the work happens, linked to the balance it supports. A log exported at year end proves far less.

• When compliance teams evaluate a close platform, they should ask the vendor to break its own rules live, starting with self-approval.

• For financial years beginning on or after 1 January 2026, Provision 29 makes close evidence board business.

Most financial close software records approvals. Far fewer tools enforce them, and the gap between recording and enforcing is where control failures start.

That gap now belongs to the audit committee. Under the UK Corporate Governance Code 2024, issued by the Financial Reporting Council (FRC), Provision 29 applies to financial years beginning on or after 1 January 2026, so the first declarations land in annual reports published from 2027. If your close sits inside the controls the board vouches for, the platform running it is part of the board's evidence.

The standard advice is to compare feature lists. A permission screen describes a control without proving it operated. Below, we answer which tools enforce approvals and sign-off, how automation builds a complete audit trail, and what compliance teams should check.

What Counts as a Control Environment in a Close Platform?

A close platform's control environment is the set of rules the system enforces, plus the evidence it keeps that those rules operated. The rules cover who can prepare, review, approve and post, and who can lock a period.

It helps to separate two layers. The policy layer is what your control framework says should happen, including segregation of duties (SoD). The execution layer is what the system makes happen on each task, every period.

Our piece on the Sarbanes-Oxley Act (SOX) as an evidence standard makes this case: auditors test what operated, whatever the policy says. UK governance now applies the same logic at board level.

Provision 29 leaves each board to decide which controls are material. The Provision 29 declaration requires a declaration of effectiveness of the material controls as at the balance sheet date. Boards must also describe any that failed.

The FRC says most companies are identifying 30 to 50 material controls, and that companies already reporting under SOX are building on their existing SOX work because Provision 29 goes further. Where reporting risk runs through the close, journal approval and reconciliation review belong on that list. The table shows how a feature list compares with a control environment.

Source: Stacks implementation practice, 2026.

Which Financial Close Tools Support Policy-Based Approvals and Sign-Off?

Financial close platforms such as Stacks enforce policy-based approvals inside the workflow, routing each task by role, value threshold, entity and account risk [VERIFY: Stacks routes approvals by value threshold and account risk]. Most close management tools now offer preparer and reviewer sign-off; the test is whether the system blocks a breach or only logs it.

A policy-based approval defines who can approve what, under which conditions, with what evidence attached. In a close management workflow, that rule is checked at the task before the work moves on.

Who Can Approve What: Roles, Thresholds and Entity Scope

The baseline is SoD: whoever prepares a reconciliation or journal cannot review it. Above that, approvals route by value threshold and account risk, so a large accrual needs a more senior reviewer than a prepayment roll-forward.

In a group, entity scope matters too. A financial controller in the Netherlands may approve for the Dutch entity only, while the group controller signs off consolidation once every entity has closed.

In our experience, the most common failure is control drift. Picture a reviewer who covers a colleague's entities during parental leave, gains preparer rights, and keeps both roles after the colleague returns. A leaver who keeps a login is the same problem in another form. Ask any financial close software vendor how the platform flags a user who holds both roles on the same task.

GL Posting Gates: Nothing Posts Until the Policy Is Met

The control auditors care about most is the gate between an approved journal and the general ledger (GL). With journal entry posting controls, journals stage for review before they reach the enterprise resource planning (ERP) system.

Posting stays blocked until approval and evidence are both present. Exceptions escalate by rule, so an unusual journal reaches a named approver instead of waiting in an inbox.

The FRC's Annual Review of Audit Quality treats journals testing as a core response to the risk of management override, and its 2025 edition found weaknesses at smaller audit firms in proving the journal population tested was complete. International Standard on Auditing (ISA) (UK) 240 requires auditors to test journal entries for this risk. A GL gate hands the auditor one complete population, each journal with its approval and support attached.

How Does Automation Create a Complete Audit Trail From Entry to Sign-Off?

Automation creates a complete audit trail by logging each action as it happens, with user and timestamp, in a record nobody can edit. The trail is a by-product of doing the work, so nobody assembles it at year end.

An audit log treated as a report shows who clicked what, but it rarely links the click to a balance. The chain of custody runs in this order:

1. Ledger data is pulled from the ERP, with the source and time logged.

2. The preparer completes the task and attaches the evidence its procedure requires.

3. The reviewer checks the work, and any change is recorded against their name.

4. The approver signs off within their threshold and entity scope.

5. The journal posts to the GL once approval and evidence are both in place.

6. Period sign-off locks the period and the evidence behind it.

Two details separate a complete trail from a tidy one. If an ERP balance changes after sign-off, the task should reopen automatically, so the evidence never describes a ledger that has since moved. The whole trail should also leave the platform in a single export.

Give your auditors read-only auditor access so they can sample inside the system. Evidence lives in the task, which cuts the prepared by client (PBC) requests your team would otherwise answer by email.

Why Standard Advice on Close Controls Fails

The common playbook is simple. Buy a tool, configure permissions at go-live, and export the audit log when the auditors arrive. In our experience, it fails in four predictable ways.

First, permissions drift, as in the parental-leave example above.

Second, evidence escapes into email. A reviewer approves in the tool while the support sits in an inbox thread, so the sample fails on documentation even though the review happened.

Third, the log exists but floats free of the numbers. An export of every click cannot tell an auditor which approval supports which balance.

Finally, teams remediate by heroics, clearing each finding with a burst of effort before the auditors sign.

A deficiency cleared by a late-night evidence hunt comes back the following year, because nothing about the process changed. Recurrence is the signature of a control that depends on people's effort. Move the control into the system, and the evidence follows.

What Should Compliance Teams Look for in a Close Platform's Control Environment?

Compliance teams should look for evidence that the financial close software enforces SoD, gates GL posting, controls access, and keeps documentation complete and immutable. Also ask for independent certification, such as a System and Organization Controls (SOC) 2 Type II report and International Organization for Standardization (ISO) 27001:2022.

Treat the demo as a walkthrough. Ask the vendor to break its own rules live, then check what the log records.

Source: Stacks audit-readiness and security documentation (stacks.ai/resources/audit-ready-by-default; trust.stacks.ai), 2026.

What to Measure Before and After

Source: Stacks implementation practice, 2026.

The connector row deserves extra attention. We treat ERP integration as a control, because a missing ledger line breaks completeness before any approval runs. A parallel run then gives you walkthrough evidence before go-live.

In most groups the close spans an ERP such as Xero, Sage, Visma, Fortnox, Exact or Unit4 alongside NetSuite or Microsoft Dynamics 365, plus subledgers in Stripe, Adyen, Chargebee, Coupa, Pleo or payroll. Every journal arriving from those systems needs the same gate.

One point for audit committees: assurance over the declaration is your call. The FRC's Provision 29 mythbuster confirms the Code does not state that the testing of the material controls should be supported by external assurance.

In PwC's Provision 29 roundtables, companies said they judge whether a control is effective by error rates, timeliness, completion rates and documentation quality. A close platform should report all four for every period, without a spreadsheet. Take your checklist results to the committee before you sign a contract.

Why Choose Stacks for Close Controls and Audit Trail

Stacks is financial close software with the controls built into each task. Preparer and reviewer roles are enforced at task level [VERIFY: SoD/preparer-reviewer roles enforced at task level], and nothing posts to the GL until it has cleared the workflow. Sign-off locks the period with its evidence.

Each task links to the policy it supports [VERIFY: each task links to the policy it supports], with embedded procedures and a timestamped activity log that cannot be altered [VERIFY: activity log cannot be altered].

Stacks holds SOC 2 Type II and ISO 27001:2022 and complies with the General Data Protection Regulation (GDPR). It adds SOX-ready controls and audit logs, with SAML SSO and SCIM [VERIFY: SCIM support] for access. Read more about our SOC 2 Type II and ISO 27001:2022 work.

Epidemic Sound signed on 29 August 2025 and went live four weeks later across 102 bank accounts and 13 entities. Its first close ran 713 tasks at 100% completion. Every one of those tasks closed with a named preparer and reviewer [VERIFY].

See how Stacks runs implementation between two closes.

FAQs for Close Platform Controls and Audit Trails

What Is a Policy-Based Approval in Financial Close Software?

A policy-based approval is a rule defining who can approve a task, under which conditions and with what evidence. The software enforces it by blocking any approval that breaks the rule.

Does Close Software Satisfy Provision 29 or SOX on Its Own?

No. The board and management own the declaration, and software supplies the execution layer and the evidence that controls operated.

How Do You Test a Close Platform's Controls in a Demo?

Try to approve your own reconciliation and post a journal with no approval attached. Then check what the log recorded.

Does Provision 29 Require External Assurance Over Material Controls?

No. The FRC leaves external assurance over the declaration to the board's judgement.

What Makes an Audit Trail Complete?

A complete trail records every action from data pull to sign-off, with user and timestamp, in a log nobody can edit. Each entry links to the balance it supports.

Should Auditors Get Direct Access to the Close Platform?

Yes, through a read-only role. Auditors sample evidence in the system directly, which cuts PBC requests and email back-and-forth.

See How Stacks Maps to Your Close Process

Book a 30-minute walkthrough. We'll discuss your close process, show you which tasks run automatically, and outline the next step from there.

GET STARTED

"Since using Stacks, we've reduced the time to financial close by three and a half days, which is material in our case. And more importantly, we've been able to utilize our resources more effectively."

Ruben A., Head of Finance, Juni

Trusted by fast-growing companies including:

Datavant, Future, Cleo, Motorway, Nivoda, Yoto, Epidemic Sound