Payroll Accounting in TouteGestion: From Approved Payroll to the General Ledger
TouteGestion deliberately separates payroll calculation from ledger policy. HR & Payroll owns the approved payroll facts; Accounting owns which General Ledger accounts those facts affect and how they are posted. The integration boundary carries an approved payroll event rather than embedding one customer's Chart of Accounts inside Payroll.
Why Payroll and Accounting have separate ownership
Payroll owns employees, approved gross pay, earning and deduction components, tax, employer contributions, currency, pay period, approval identity and immutable calculation snapshots. Accounting owns ledger-account mapping, debit/credit treatment, cost-centre policy, journal creation, posting periods and ledger controls. This keeps payroll calculations stable even when an organisation restructures its Chart of Accounts.
1. Approve the payroll in HR & Payroll
The accounting boundary is reached only when a genuine payroll run reaches the governed approval state. HR & Payroll then produces one idempotent payroll.run.approved event for that approved run. Draft or merely calculated payroll is not presented as final accounting activity.
2. Publish semantic payroll components
The approved event describes payroll meaning rather than hard-coded customer account numbers. Component keys can represent items such as base pay, employee social-security deduction, PAYE tax and employer contribution. The semantic keys remain stable while each tenant's Accounting mappings can evolve independently.
3. Deliver through the Payroll accounting outbox
HR & Payroll retains accounting_outbox events with event type/version, idempotency key, payload, status, attempt count, availability, delivery time and error details. The Payroll Accounting page surfaces Pending/Processing, Delivered, Failed and Dead-letter states so integration failures remain visible rather than disappearing between products.
4. Map each payroll item inside Accounting
Accounting → Accounting mappings shows Payroll accounting rows grouped by payroll component. Finance selects the debit and credit account for each component line. Changing these mappings changes future accounting treatment; the page explicitly states that it does not change the payroll calculation itself.
5. Keep the Chart of Accounts out of Payroll
This boundary is intentional. Payroll does not need to know whether one organisation calls its salary expense 5100 Salaries and another uses 601100 Personnel Costs. Accounting resolves the semantic component to the tenant's current accounts, allowing international and organisation-specific charts without forking payroll logic.
6. Do not silently post unmapped transactions
Accounting exposes transactions waiting for account assignment when a received financial event lacks a usable treatment. Simple events can be resolved to selected accounts; composed events such as payroll require the related component mappings to be corrected. The system also surfaces processing errors separately so Finance can correct mapping or source data before retrying.
7. Preserve idempotency and delivery history
The integration contract uses an idempotency key and retained outbox history. That matters because a retry after a temporary failure must not become a second payroll expense. Delivery status, attempts and errors give operators evidence of what happened at the product boundary.
8. Payroll deductions can connect to other Accounting subledgers
The current architecture also includes an Accounting advance-recovery bridge: configured payroll deduction components can recover employee advances using Accounting-owned posting mappings. This illustrates the intended model—Payroll carries the approved deduction fact, while Accounting decides how that fact settles or reduces the relevant financial balance.
Worked example
A September payroll is approved with Basic Salary, employee social-security deduction, PAYE, employer social-security contribution and Net Pay. HR & Payroll emits the approved semantic event and records its delivery state. In Accounting, Finance maps Basic Salary to salary expense/payroll clearing, PAYE to the appropriate tax liability treatment and the other components to their configured accounts. If one required component is unmapped, the exception remains visible rather than being forced into a generic suspense account without review.
What the customer must configure
The organisation must maintain a suitable Chart of Accounts and assign the Accounting mappings for its payroll components. HR/Payroll administrators remain responsible for correct payroll setup and approval; Finance remains responsible for accounting mappings and ledger controls. TouteGestion connects the two without collapsing those responsibilities into one role.
Practical configuration checklist
- payroll run genuinely approved before accounting delivery
- payroll semantic components reviewed for the organisation's payroll setup
- Accounting posting-rule permission assigned to Finance administrators
- debit and credit account selected for each required payroll component
- Payroll calculation not altered merely to fit the Chart of Accounts
- outbox pending, delivered and failed states monitored
- unmapped payroll components corrected in Accounting mappings
- processing errors corrected before retry
- idempotent event delivery retained to prevent duplicate accounting
- advance-recovery deductions mapped where that workflow is used
- Payroll and Accounting ownership boundaries preserved
Connect accounting structure, workflow and reporting.
Explore the product or continue through the Accounting Knowledge Centre.