How to reconcile payroll to the general ledger with an AI agent

Payroll reconciles in three places: the payroll register against the journal posted to the ledger, the net pay and deductions against what left the bank, and the liability accounts against what was paid to tax authorities and pension schemes. An agent can do all three from totals, without seeing individual pay. A person approves corrections and signs.

What does payroll-to-ledger reconciliation cover, and who owns it?

Each pay run produces a register: gross pay, employer costs, deductions and net pay, by employee and element. A summary journal posts it to the general ledger: expense by cost centre, and liabilities for net pay, income tax, social security, pensions and other deductions. Then payments clear those liabilities: net pay to employees, deductions to the bodies owed them.

The payroll manager owns the register. The payroll or general ledger accountant owns the journal and the liability accounts. The financial controller signs the reconciliation. Errors here can be costly and slow to correct: an unpaid tax liability attracts penalties, and an expense posted to the wrong cost centre distorts every management report.

Whether an agent can run payroll is a different question; this playbook is about checking it after the fact.

What are the steps, and at what depth?

1. Agent, depth 1: reads register totals. By pay run, cost centre and element. Not individual records, unless a difference needs tracing and a person grants access for that case.
2. Agent, depth 1: reads ledger postings. Payroll expense and liability accounts for the period, with read-only access granted as in giving an AI agent read access to your general ledger.
3. Agent, depth 1: ties register to journal. Each element's total in the register against the posting, and each cost centre's total against the expense posted there.
4. Agent, depth 1: ties payments. Net pay total against the bank payment, as matched in the bank-to-ledger reconciliation; each deduction's total against payments to the relevant body.
5. Agent, depth 1: reconciles liability accounts. Opening, accrued from payroll, paid, closing, per liability. Balances should clear on the expected payment cycle.
6. Agent, depth 2: explains differences and drafts corrections. Mapping errors, manual payments outside the run, off-cycle runs not posted, late payments. Correcting journals are parked.
7. Person, payroll accountant: approves corrections. With the payroll manager where the register itself is wrong.
8. Person, controller: signs.

Which controls matter, and what evidence does each leave?

Totals, not individuals. The agent works at aggregate level by default. Evidence: an access log showing when, why and by whose approval individual records were opened.

Element mapping. Each payroll element maps to one ledger account, under change control. Evidence: the mapping version on the reconciliation.

Every run included. Off-cycle and correction runs are listed and tied. Evidence: the run list for the period against journals.

Liabilities clear on time. A balance older than the payment cycle is a missed or wrong payment. Evidence: liability ageing.

Tested mapping changes. Changes to mapping or matching rules are tested on past periods before use, as in testing an AI agent before it touches the general ledger. Evidence: test results.

What does a difference look like?

Take an illustrative company whose register shows pension deductions of 42,000 for the month, while the pension liability account received 40,500. The agent traces the 1,500 to a new pension element created for a salary sacrifice scheme and not yet mapped, so the payroll system posted it to a general deductions account. It drafts a correcting journal and a mapping change for the payroll accountant, and notes that the pension scheme should be paid the full 42,000. The accountant approves the journal, the payroll manager fixes the mapping, and treasury pays the difference.

What should you measure?

• Register-to-ledger differences per run.
• Liability balances past their payment cycle.
• Unmapped elements found.
• Requests for individual-level access, and how many were needed.
• Days from pay date to signed reconciliation.

Where does it usually go wrong?

New elements unmapped. A new allowance or deduction posts to a default account. The agent should list any element with no explicit mapping each run.

Off-cycle runs forgotten. A correction run for a leaver is paid but never posted. Tie every run in the payroll system to a journal.

Manual payments. An urgent payment to an employee outside payroll is posted to a payroll account. The register does not include it, so a difference appears. Record manual pay through payroll wherever possible.

Liabilities netted. Different deductions are posted to one liability account, so an underpayment of one hides behind an overpayment of another. Keep one account per body owed.

Too much personal data. The agent is given the whole register "to make matching easier". Totals are enough for almost every difference.

Where Pryme fits

In Pryme, register tying, liability reconciliation and drafting corrections are separate capabilities certified on your own past pay periods. Register totals arrive sealed from the payroll system and bank payments signed by the bank. Access to individual records is a separate, narrower grant, and every opening is filed. The finance bounds are in AI agents for finance.