Payroll is one of the most consequential financial operations a business runs. Every pay cycle touches employees, statutory obligations, bank accounts, and the general ledger simultaneously. Getting any one of those wrong has real consequences for the business, for compliance, and for the people being paid.
Monesize Core v1 has always had a manual payroll module. It lets finance teams build pay runs from employee records, approve them, mark them as paid, and post the journal entry to the accounting ledger. That works well for smaller teams running straightforward payroll. But mid-market businesses with dozens or hundreds of employees typically do not run payroll manually inside a financial operations platform. They use a dedicated payroll provider like Gusto or Deel that handles the statutory calculations, tax filings, and direct deposits that come with running payroll at scale.
The problem those businesses have is not payroll calculation. It is the downstream record-keeping. When a payroll provider processes a pay run, the accounting entry has to be made somewhere. The default approach is a spreadsheet, or a manual journal entry, or an export and import between systems. All of that is error-prone, slow, and invisible to anyone not directly involved in the process.
The Payroll Integration Layer in Monesize Core solves this. It connects to external payroll providers, imports completed pay runs with full statutory breakdown, and posts an accurate multi-line accounting journal automatically. The finance team stops doing manual reconciliation work. The ledger reflects what actually happened.
What the module does
The Payroll Integration Layer is a bridge between your payroll provider and Monesize Core’s accounting ledger. It has two jobs.
The first job is employee synchronisation. When you connect a provider, the module can pull the current employee list from that provider and upsert it into Core’s Employee model. This keeps the two systems aligned without manual data entry on both sides.
The second job is payroll run synchronisation. At the end of a pay period, the finance team triggers a sync for that period. The module pulls the completed, processed pay run from the provider, maps every employee’s pay breakdown to Core’s data model, and creates a fully populated payroll run record with status set to Paid. Because the run came from an external provider where the disbursement already happened, it is marked as paid immediately. The accounting journal fires automatically on import.
Both operations are triggered manually by the finance team from the Integrations tab on the Payroll page. There is no automatic background polling. This is intentional. Payroll is a high-stakes operation and the team should make a deliberate decision to import a run, review it, and confirm it is correct before it hits the ledger.
The accounting journal and what changes
This is the most important part.
Before Monesize Core v2, every payroll run posted a single two-line journal entry when marked as paid. Debit Salary Expense for the total net pay, credit Cash for the same amount. That is correct for a manual payroll where the platform has no visibility into the statutory components. The net pay left the business and was recorded as salary expense. Simple, defensible, but incomplete.
When a payroll provider imports a run with full statutory data, that two-line entry is not accurate. The employer’s true cost is not just the net pay. It also includes employer National Insurance contributions, employer pension contributions, and the employer’s share of other statutory costs. The liabilities sitting on the balance sheet after a pay run include amounts owed to HMRC for PAYE, amounts owed to the NI system, and amounts owed to the pension provider. None of that appears in a net-pay-to-cash entry.
The Payroll Integration Layer replaces the simple entry with a full statutory journal for provider-imported runs. The journal structure is:
Debit 5020 Salary Expense for the total gross pay across all employees. Debit 5230 Employer National Insurance for the total employer NI contributions. Debit 5240 Employer Pension Contribution for the total employer pension contributions. Credit 2100 PAYE and Tax Liability for the total income tax withheld. Credit 2110 National Insurance Liability for the combined employee and employer NI. Credit 2120 Pension Liability for the combined employee and employer pension contributions. Credit 1000 Cash for the total net pay, which is the actual money that left the bank account.
Every debit and every credit is computed from the per-employee statutory breakdown the provider returns. The debits represent the full cost to the business. The credits represent the liabilities created and the cash that left the account. The journal balances to the cent.
Five new accounts are seeded into the Chart of Accounts to support this structure. PAYE and Tax Liability sits at code 2100. National Insurance Liability sits at code 2110. Pension Liability sits at code 2120. Employer National Insurance expense sits at code 5230. Employer Pension Contribution expense sits at code 5240. These accounts appear in the balance sheet liabilities section and the income statement operating expenses section respectively.
The accounting module automatically chooses between the simple entry and the statutory entry based on whether the payroll run contains statutory data. Manual payroll runs that have no statutory breakdown continue to post the existing two-line entry. Nothing about manual payroll changes.
How the sync works in practice
The Integrations tab on the Payroll page shows the connected providers and their status. A finance team member with admin access connects a provider by selecting it from the list, entering the required credentials, and clicking Connect.
Gusto requires a Company ID and a Bearer access token. Deel requires an API key. The credentials are stored in the database associated with the integration record. They are never returned in API responses. Only the connection status and last sync timestamp are visible after connection.
Once connected, the finance team has two sync operations available.
The employee sync pulls the current worker list from the provider and upserts each employee into Core’s Employee model. It matches on an external ID key derived from the provider’s employee identifier. If an employee already exists in Core with a matching ID, the name, role, and salary are updated from the provider. If no match is found, a new employee record is created. The sync result tells the team how many employees were created and how many were updated.
The payroll run sync takes a period start and end date, queries the provider for completed pay runs in that period, and imports the first matching run. Each employee’s statutory breakdown is mapped to the corresponding fields on the PayrollItem record. The run is created in Core with status Paid and is immediately available in the Payroll runs tab with the full statutory breakdown visible in the expanded row view.
The system prevents duplicate imports. If a run with the same provider reference has already been imported, the sync returns a clear message and does not create a duplicate record.
What is stored per employee per run
For every employee in an imported payroll run, Core stores the following:
Gross pay, which is the employee’s full compensation before any deductions. Net pay, which is the amount actually paid to the employee after all deductions. Allowances and deductions as aggregate figures. Income tax, which is the PAYE or federal withholding amount deducted from the employee’s pay. Employee National Insurance, which is the employee’s NI contribution. Employer National Insurance, which is the employer’s NI contribution on top of the employee’s pay. Employee pension contribution, which is the amount deducted from the employee’s pay for pension. Employer pension contribution, which is the employer’s top-up to the pension scheme. Student loan deductions where applicable. Other statutory deductions that do not fit into the above categories. The full raw statutory breakdown from the provider stored as a JSON audit field.
When a finance team member expands a payroll run in the Payroll runs tab, the items table shows all of these columns for provider-imported runs. For manual runs the table shows the existing compact view with basic, allowances, deductions, and net pay.
What the module does not do
The Payroll Integration Layer is a record-keeping layer. It does not calculate payroll. It does not file PAYE returns or pension submissions. It does not initiate payments to employees or to HMRC. Those functions remain with the payroll provider.
The module imports what the provider has already done, records it accurately, and posts the correct accounting entries. The responsibility for statutory accuracy sits with the payroll provider. Core’s job is to make sure that accuracy is reflected faithfully in the books.
Provider support
The initial release supports Gusto and Deel. Both providers have publicly documented REST APIs that allow reading employee data and completed payroll runs.
Gusto is widely used by US-based businesses with salaried and hourly employees. Its API returns per-employee gross pay, net pay, employee taxes broken down by federal and state, employee deductions for benefits and retirement, and employer contributions. Monesize Core maps all of these to the statutory breakdown fields on each Payroll Item.
Deel is widely used by businesses with international contractors and remote employees. Its payments API returns per-worker gross amounts, net amounts, and tax figures. Monesize Core maps these to the same fields.
The integration layer is built on a provider adapter interface. Adding a new provider means writing a single adapter file that implements two methods: one that fetches employees and one that fetches a completed payroll run for a period. The service layer, schema, accounting journal logic, and frontend are already in place. Adding Rippling and ADP will require obtaining API access through their respective partner programs, at which point the adapters can be built and dropped in without any changes to the rest of the system.
How it fits into the wider platform
The Payroll Integration Layer sits cleanly within Monesize Core’s event-driven architecture. When a payroll run is imported, it emits the same payroll paid event that a manual run emits when marked as paid. The accounting module listens for that event and posts the appropriate journal. This means the integration layer required no changes to the accounting module’s listener registration or event handling logic. It only extended what the handler does once it receives the event.
The journal entries produced by imported runs appear in the accounting ledger alongside every other journal in the system. They can be viewed in the Chart of Accounts, included in financial reports, and audited at the line level. The source module and reference fields on each journal entry link directly back to the payroll run that triggered it, so the audit trail from journal entry to provider run is a single lookup.
For businesses using the UK HMRC MTD module, the PAYE and NI liability accounts posted by payroll runs flow correctly into the balance sheet and give the finance team a running view of what is owed to HMRC outside of VAT. For businesses using the Canada GST/HST module, the same principle applies to their payroll liabilities under Canadian employment standards.
Who this is built for
The Payroll Integration Layer is designed for mid-market businesses that have moved beyond spreadsheet payroll and are running Gusto or Deel as their payroll system of record, but have not had a clean way to get the statutory breakdown of each pay run into their accounting ledger without manual work.
It is specifically valuable for finance teams that currently spend time each pay period exporting reports from their payroll provider, building manual journal entries in a spreadsheet or accounting system, and reconciling those entries against bank statements. That entire process is replaced by a single sync operation that takes a few seconds and posts an accurate, fully detailed journal entry automatically.
It is also valuable for businesses preparing for audit. An auditor reviewing payroll accounting entries will find, for each pay period, a journal that shows gross pay, employer NI, employer pension, PAYE liability, NI liability, pension liability, and net cash paid. Every figure is traceable to the provider run that produced it. There are no lump sums, no unexplained entries, and no missing statutory costs.
Monesize Core is a modular financial operations platform built for mid-market businesses. The Payroll Integration Layer is available on request. Current provider support covers Gusto and Deel. Additional providers will be added as partner API access is established. See how Monesize Core connects payroll, accounting, and business operations in one platform at monesize.com.