Journal entry automation that survives an audit

Journal entry automation survives an audit when every entry carries its own evidence. Not the schedule sitting in a shared drive. Not the approval buried in a Slack thread with no link back to the entry. The support, the approver, the logic that produced the amount and the reversal path, all attached to the entry and retrievable nine months later.

Most vendors demo the posting. Posting is the easy part. The hard part arrives when an auditor samples entries from a population your team no longer remembers generating, and asks who prepared them. This post covers what auditors commonly request and the three things automated entries usually miss.

Key takeaways

• The audit risk in journal entry automation is evidentiary, not computational. The amount is usually right. The trail behind it is usually thin.

• Three gaps cause most audit friction: support stored apart from the entry, approvals recorded outside the system of record, and corrections made by hand instead of through a defined reversal path.

• A deterministic workflow produces the population, the logic version and the approver as a byproduct of running. A spreadsheet-and-upload process reconstructs them weeks later.

• Not every entry should be automated. Top-side adjustments are the honest exception.

• The amount should never come from a language model. On the FinanceReasoning benchmark (ACL 2025, arXiv:2506.05828), numerical calculation errors accounted for roughly 37.5% of model failures across 2,238 problems.

Here is the difference an auditor sees, request by request.

| What an auditor asks | What a spreadsheet-and-upload process produces | What a deterministic workflow produces | | --- | --- | --- | | The full population of automated entries | A filtered export plus a memo on which entries were manual | A run log listing every entry posted, with the run that produced it | | Who prepared this entry | A user ID belonging to whoever uploaded the file | The workflow, its version and the run identifier, approver named separately | | The supporting schedule | A file path, a search, and someone's recollection | Support attached to the entry at posting time, linked to the run | | Who approved it and on what basis | A Slack screenshot or a forwarded email | An approval record with timestamp, approver and values shown | | Whether the logic changed during the period | A verbal answer | A version history showing each change, who made it, and the first run affected | | Every correction to this entry | A second entry with a note in the memo field | A reversal record linked to the original entry and run |

Why automated journal entries fail at audit rather than at posting

Automated journal entries rarely fail because the number is wrong. They fail because nobody can reconstruct how the number came to exist. Evidence is cheap to capture at posting and expensive to assemble later. A prepaid amortisation schedule takes seconds to attach when the entry posts. Nine months later it takes an email chain, a former colleague, and a file that may no longer match what posted.

In the Protiviti 2025 SOX survey, nearly 70% of organisations reported implementing automated compliance tools, and 68% said they are prioritising more technology and automation. APQC research covering more than 10,000 organizations puts top performers at five days or less to close and bottom performers at 10 or more calendar days. Teams compress the calendar by automating entries, then give the time back during fieldwork. The gap is between automating the work and automating the record of the work.

What an auditor asks when an entry has no human preparer

With no human preparer, auditors commonly shift from testing the entry to testing the process that produced it. Five requests recur.

The population. Which entries did this process generate during the period, and how do you know the list is complete?

The logic version. What rule produced this amount, and was it the same rule on the first day of the period as on the last? A formula changed in week two leaves no trace.

The approver. Who reviewed this entry before it posted, and what did they see? Not who holds approval rights. Who approved this one.

The support. The schedule, contract or invoice the entry rests on, in the version used at posting.

Change control. Evidence that the logic did not change mid-period without authorisation.

Loopfour, the deterministic finance workflow automation platform, produces these five artefacts as a byproduct of execution rather than as a reporting exercise. Every run writes an execution tree: each block that ran, its inputs and outputs, the branch it took, and every human decision along the way. Execution is programmatic, so run number one and run number one million behave identically.

None of this is a legal or audit opinion. Requirements vary by auditor, entity and materiality. This describes evidence auditors commonly request.

Support attachment: the entry posts, the schedule stays behind

Support attachment means the source document and the calculation travel with the entry into the general ledger at posting. Most automated entries skip this. The entry lands in NetSuite or Sage Intacct, and the schedule that justified it stays in a folder. The cost stays invisible until fieldwork, then it is measured in hours per sampled entry: finding the file, confirming it produced the posted amount, and explaining the difference when it did not.

Loopfour attaches support at posting time. A recurring accrual workflow assembles the schedule, computes the amount, posts to the ledger, and attaches the file and calculation in the same run. The entry carries the run identifier, so the execution tree is one click away.

NetSuite trial balance → Loopfour Studio schedule block → amount computed → approval routed in Slack → entry posted to NetSuite with support attached → execution tree written

Two details matter more than they sound. The support must be the version used on that run, not the current copy of a file that kept changing. And the link must survive people leaving: attachment inside the ledger plus a link to the run, not a folder path in a memo field.

The Invoice Agent and Contract Agent handle documents originating outside the ledger, and their extracted values ride along as support. Extraction is a scoped task with a confidence threshold, and anything below it becomes an exception routed to a person before the entry posts.

Approval evidence: who approved this entry, when, and on what basis

Approval evidence is the record showing that a named person reviewed a specific entry, at a specific time, seeing specific values. An approval that cannot be tied to the posted amount is weak evidence, however real it was.

Slack is where this breaks. A controller types "approved" in a thread. The entry posts. Nine months later the thread is searchable, the entry sits in Xero, and nothing connects them. The message also does not show what the approver saw, which matters when the amount changed afterwards.

Loopfour records approval as a step in the run. The human-in-the-loop block presents the entry, the amount and the support, then captures approver identity, timestamp, decision and displayed values. The notification still arrives in Slack, Gmail or Outlook. The evidence lives in the run.

Segregation of duties changes shape when the preparer is a workflow. It does not disappear. The workflow and its version become the preparer of record. Whoever edits that workflow on the canvas cannot be the sole approver of its output, and the approver holds no edit rights over the logic that produced the amount.

This is where the managed service matters. We build, monitor and maintain the workflows. Your team approves the exceptions. The people who change the logic and the people who approve the entries are different groups, and the platform records both sides.

Set approval gates by risk, not by habit. A human on every depreciation entry produces rubber-stamping, which tests worse than no gate at all. A human on every revenue entry with a manual input is defensible and cheap.

Reversibility: what happens when an automated entry is wrong

Reversibility means a wrong entry has a defined correction path that produces its own audit record. Automation does not eliminate wrong entries; it changes how they are found and fixed.

The common failure is the quiet fix. Someone spots the error, posts an adjusting entry by hand, writes a memo, and moves on. The original entry has no link to its correction, the workflow still reports success, and the trail breaks twice.

Loopfour treats reversal as a workflow. A reversal sub-workflow posts the reversing entry, links it to the original entry and run, records who authorised it, and captures the reason. If the logic caused the error, the fix is versioned on the canvas and the history shows the first run affected.

• Reverse, then repost. A clean reversal plus a corrected entry tests better than an in-place edit.

• Record the trigger. Note whether the error surfaced from a workflow exception, a reconciliation break or a person. Auditors ask how errors are detected, not only how they are fixed.

• Treat repeated reversals as a control signal. The same entry type reversing three months running is a logic defect.

The AI Copilot's Debug mode explains why a run produced a given result by walking the execution tree. It explains the run. It does not touch the entry.

Which journal entries to automate, and which to leave alone

Most recurring entries are safe to automate. Judgement-heavy entries are not, and honesty about that boundary is what makes the automated population defensible.

| Entry type | Automatable | Support required | Approval gate needed | | --- | --- | --- | --- | | Recurring accruals | Yes | Accrual schedule, source invoices | No, with variance alert | | Prepaid amortisation | Yes | Prepaid schedule, original invoice | No, with variance alert | | Depreciation | Yes | Fixed asset register, method and life | No | | Revenue recognition | Yes, with rules per contract type | Contract, performance obligation mapping | Yes, on new or modified contracts | | FX revaluation | Yes | Rate source, exposure listing, rate date | No, with rate source check | | Intercompany | Yes | Both entity extracts, elimination mapping | Yes, when out of balance | | Reclassifications | Yes, where the rule is stable | Original entry reference, reclass rule | Yes, above materiality | | Top-side adjustments | No | Management memo, supporting analysis | Yes, human-prepared and approved |

Revenue recognition deserves a note. The ASC 606 five-step model issued by the FASB governs revenue recognition under US GAAP. Automation handles the mechanical part: the schedule, the allocation once determined, the periodic entry. Identifying performance obligations in a non-standard contract is judgement, and belongs with your revenue accountant. The Contract Agent flags contracts that differ from your standard template.

Why the amount is computed programmatically and a model never touches it

Loopfour computes journal entry amounts in code, not in a language model. The reason is measurable. On the FinanceReasoning benchmark published at ACL 2025 (arXiv:2506.05828), covering 2,238 problems, the strongest reasoning model tested reached 89.1% on the hard subset using Program-of-Thought prompting, and numerical calculation errors made up roughly 37.5% of failures. That leaves roughly one in nine hard problems wrong, much of it arithmetic. That rate is unacceptable for an entry posting to the general ledger.

So the division of labour is fixed:

• Deterministic code computes every amount, allocation and rounding decision. Same inputs, same output, every run.

• AI handles scoped extraction and classification with confidence thresholds. Reading a vendor name from a PDF invoice. Matching a line item to a coding rule. Below the threshold, a person decides.

• The AI Copilot assists the builder, not the ledger. Ask explains a workflow, Build drafts one on the canvas, Debug traces a run. None of them post entries.

This is not "an AI agent with a wrapper" running your close. Loopfour is not a black box: every action lands in the execution tree, and the logic is visible on the canvas as blocks a controller can read.

The upstream evidence points the same way. IOFM puts the manual invoice error rate at roughly 2% against below 0.8% automated, and Levvel Research puts manual cost per invoice at $10 to $15 against $2 to $3 automated. Ardent Partners finds over 60% of invoices still require human interaction, which is why human-in-the-loop is designed in rather than bolted on.

How to decide what to automate first

Start with entries that are high volume, rule-stable and already supported by a schedule someone maintains. Four questions rank a candidate in about 10 minutes.

| Question | Automate now | Automate later | Keep manual | | --- | --- | --- | --- | | Is the calculation rule written down and stable? | Unchanged for two or more quarters | Shifts with facts | Judgement each period | | Does the support already exist in a system? | Yes, in NetSuite, QuickBooks, Xero, Sage Intacct, Rillet or Stripe | In files with consistent structure | Assembled by hand | | Would an error be caught before filing? | Yes, by an existing reconciliation | Only by review | Not reliably | | How often does it post? | Monthly or more | Quarterly | Annually or ad hoc |

A modelled scenario shows the payoff. Take a controller posting 120 recurring entries a month, each needing eight minutes to prepare and attach support by hand, plus two hours per sampled entry to reassemble evidence across 25 audit samples. Automating that population projects to roughly 16 hours of monthly preparation removed and 50 hours of audit support avoided. Those figures are illustrative, not results from a named customer.

Then sequence the build.

Depreciation and prepaid amortisation → recurring accruals → FX revaluation → intercompany → revenue recognition schedules → reclassifications

Top-side adjustments stay where they are, prepared and approved by people.

Frequently asked questions

Can journal entries be fully automated?

Most recurring entries can be, including accruals, prepaid amortisation, depreciation, FX revaluation and intercompany postings. Judgement-heavy entries should not be: top-side adjustments and non-standard revenue contracts need a human preparer. A defined automated population with a documented manual remainder is more defensible than full automation.

What audit evidence do automated journal entries need?

Auditors commonly request five items: the complete population the process produced, the logic version behind each entry, the named approver and what they saw, the support as used at posting, and evidence that the logic did not change mid-period without authorisation. Capture these at posting; reconstructing them during fieldwork is where the hours go.

How do you maintain segregation of duties when a workflow prepares the entry?

Treat the workflow and its version as the preparer of record, then separate two rights: who changes the logic on the canvas, and who approves the resulting entries. Those cannot be the same person for one entry type. Under Loopfour's managed service, we build and maintain the workflows while your team approves exceptions, which keeps the groups distinct.

Is a Slack approval enough evidence for a journal entry?

An approval message in Slack with no link to the posted entry is weak evidence. It does not show which entry was approved, what the approver saw, or whether the amount changed afterwards. Notification in Slack is fine. The approval record belongs in the system that posted the entry, with approver identity, timestamp, decision and displayed values.

How do you correct an automated journal entry that posted wrong?

Run a reversal as a defined sub-workflow rather than a manual adjusting entry. The reversal posts, links to the original entry and run, records who authorised it and why, and leaves its own audit record. If the logic caused the error, version the change on the canvas so the history shows which runs were affected. A hand-typed correction breaks the link between error and fix.

Does Loopfour use AI to calculate journal entry amounts?

No. Amounts, allocations and rounding are computed in deterministic code, identical on run number one and run number one million. AI is called for scoped tasks such as extracting a vendor name from a PDF or classifying a line item, each with a confidence threshold and a human fallback. The FinanceReasoning finding, roughly 37.5% of failures coming from numerical calculation errors, is the reason for that boundary.

Which finance systems does Loopfour work with, and how is data secured?

Loopfour Studio connects to QuickBooks, NetSuite, Xero, Sage Intacct and Rillet for ledger posting, and to Stripe, Salesforce, HubSpot, Attio, Slack, Gmail, Outlook, DocuSign, PandaDoc, Dropbox Sign and Workday for source data, approvals and documents. Workflows are built from 30 blocks across seven categories. Loopfour is SOC 2 Type II certified, with a SOC 1 audit underway and HIPAA controls, uses AES-256 at rest and TLS 1.3 in transit, and never uses your data to train models.

The entry is only as good as what is attached to it

Every vendor can show you an entry posting. Ask the harder question in the demo: show me this entry nine months from now, with its support, its approver, its logic version and its reversal history, retrieved in one action. That demo predicts your fieldwork.

Deterministic execution, evidence captured at posting time, and human approval where warranted. Those three make journal entry automation hold up under sampling.

Book a workflow review with our team. We will map your entry population, mark what is safely automatable, and show what the evidence package looks like on each one.