Every month, in finance teams across the UK, the same ritual plays out. Payroll is approved, staff are paid, and a few days later someone in finance opens a PDF from the payroll bureau and starts typing numbers into the ledger. It is one of the last fully manual jobs in many finance departments, and in Dynamics 365 Business Central it is almost always avoidable.

This post looks at how payroll typically reaches the finance system, where the errors come from, and how payroll integration with Business Central turns a two-hour keying exercise into a short review.

How payroll usually lands in the ledger

Most small and mid-sized UK businesses run payroll outside their ERP. It might be an in-house payroll package, a cloud platform or an outsourced bureau. That system calculates pay, deducts PAYE and National Insurance, and sends the Full Payment Submission to HMRC under Real Time Information (RTI) on or before payday.

What it rarely does is talk to the general ledger. So once the pay run closes, finance receives a payroll summary or journal report and has to translate it into a payroll journal. A typical monthly journal includes:

• Gross pay, often split by department, cost centre or project
• Employer costs, including employer National Insurance (currently 15% above the secondary threshold of £5,000 a year) and employer pension contributions under auto-enrolment
• Deductions and liabilities, such as PAYE and NI owed to HMRC, employee and employer pension contributions owed to the provider, student loan repayments, salary sacrifice and any attachment of earnings
• Net pay, posted to a wages control account and cleared when the BACS payment goes out

In Business Central, these lines are keyed into a general journal, tagged with the right dimensions and posted. Some teams speed this up with a recurring journal template, but the amounts still have to be typed in every pay run.

Where manual journal entries go wrong

None of this is difficult accounting. The problem is volume and repetition. A business with 60 staff across four departments can easily produce a payroll accounting journal of 30 to 50 lines each month, plus extra runs for bonuses, leavers or corrections. Every one of those lines is a chance to make a mistake.

Research on spreadsheet and keying accuracy backs this up. In his review of spreadsheet error studies, Raymond Panko found that cell error rates in laboratory experiments were at least 1% to 2%, and that field audits found errors in a large share of the spreadsheets examined. Re-keying a payroll summary is exactly the kind of work that produces these slips.

The errors we see most often in manual payroll postings are:

1. Transposed or mistyped figures. £4,819 becomes £4,891, and the journal still balances if the same slip is made on the other side.
2. Wrong dimension or cost centre. Salaries land in the wrong department, which distorts departmental P&Ls and budget reporting for months before anyone notices.
3. Wrong posting date or period. A pay run keyed on the 2nd of the following month ends up in the wrong period, and accruals have to be unpicked.
4. Liability accounts that never clear. If the HMRC or pension liability is posted with a different figure from the one actually paid, a small balance sits on the balance sheet and has to be investigated at month-end.
5. Missed or duplicated runs. Supplementary pay runs are easy to forget, and a journal keyed twice is surprisingly easy to post.

Each of these creates reconciliation work later. The time lost is not just the keying itself, but the checking, the investigating and the corrections that follow, often at the busiest point of the month when finance is trying to close the period.

How payroll integration with Business Central works

The goal of payroll integration is simple: the payroll system produces the journal, and Business Central posts it. There are three common ways to get there.

1. Business Central's payroll import. Business Central includes an Import Payroll Transactions action on the general journal. You map the payroll provider's account codes to your G/L accounts once, and Business Central remembers the mapping for every future import. The journal is populated automatically, and you review and post it like any other. This relies on a payroll import extension being installed and your payroll software producing a compatible export file.

2. A payroll connector. Several UK payroll providers and Microsoft partners offer connectors that send the payroll journal straight into Business Central through its standard APIs. The journal arrives in a named batch, already coded with G/L accounts and dimensions and ready for approval. No file handling is involved.

3. Payroll alongside the HR module. Business Central's Human Resources area holds employee records, contracts, qualifications and absence. It does not calculate UK payroll on its own, but pairing it with a payroll add-on or connector means employee data is maintained in one place and pay results flow back to finance without re-keying. This suits businesses that want HR and finance data to share the same source.

Whichever route you choose, the principle is the same. The mapping is set up once, validated and reused. Finance moves from creating the journal to checking it.

Before and after: a finance assistant's pay run

Here is an illustrative example based on a typical mid-sized business with 60 employees paid monthly.

Before integration

On the day after payroll closes, the finance assistant downloads the bureau's journal report as a PDF. She opens a general journal batch in Business Central and types in around 40 lines: gross salaries for four departments, employer NI, employer pension, the HMRC liability, the pension liability, student loan deductions and net pay. She adds department and cost centre dimensions line by line, checks the batch balances and posts it.

The whole job takes about two hours. If the totals do not tie back to the payroll report, add another hour to find the typo. At month-end, the HMRC liability account has a £38 difference that takes the financial controller half an afternoon to trace. It turns out to be a transposed figure from two months earlier.

After integration

The payroll system produces an export in the agreed format as part of closing the pay run. The finance assistant opens the payroll journal batch and runs the import, and the 40 lines appear with accounts and dimensions already applied. She compares the batch total to the payroll summary, checks one or two departmental figures and posts.

The job now takes around 15 minutes. The liability accounts clear to zero when HMRC and the pension provider are paid, because the posted figures come from the same source as the payments. The time saved goes into reviewing variances and supporting month-end reporting, which is a far better use of a skilled team member.

What to check before you automate

Integration works best when the groundwork is right. Before switching on automated payroll posting, it is worth confirming:

• Your chart of accounts has clear, separate accounts for each payroll liability
• Dimensions for departments, cost centres or projects match how payroll codes employees
• A payroll control or clearing account is in place for net pay
• Someone owns the mapping and knows to update it when a new department, pension scheme or pay element is added
• An approval step remains in place, so a person still reviews each journal before it posts

Talk to Creative Computing about payroll integration

If your team is still re-keying payroll into Business Central every month, there is almost certainly a better way. The right option depends on your payroll provider, how you use dimensions and whether you want HR data in Business Central too.

Speak to Creative Computing about payroll integration options for your Business Central setup. We'll look at how your payroll data reaches the ledger today and recommend the simplest way to automate it.