Posting Payroll & Journals
What Post payroll does, how each pay-item group is mapped to accounts, and why the mapping is remembered.
Post payroll on a draft pay run is the moment payroll becomes financial. It is one deliberate action, and it cannot be undone.
What posting does
One journal entry, carrying a debit line and a credit line for every pay-item group, using the accounts you map in the dialog. It is dated the run's pay date, referenced PAY- followed by the run's subject, and each line is described as the group name, its type, and how many employees are behind it.
It stops being editable.
Available immediately for download or email.
There is no un-post. If a posted run is wrong, correct it through Finance the way you would correct any other posting — never by trying to edit the run. Review before you post: see Reviewing a pay run.
The posting dialog
The dialog is titled Finalize Payroll followed by the run's subject. It opens with a summary — total employees, payroll items, total amount — then Journal Entry Configuration.
Your pay items are collected into groups by name and type. Every group with the same name and type across the whole run is one group: every "Basic salary" line is one group, every "Income tax" line is another. For each group you choose a debit account and a credit account.
| Requirement | Why |
|---|---|
| A debit account | Where the value lands as a charge. |
| A credit account | Where the corresponding obligation or reduction lands. |
| The two must be different | A group mapped to the same account on both sides posts nothing meaningful, so it is rejected. |
A counter reads "N of M groups mapped" so you always know exactly how much is left. Under it, a Journal Entry Summary shows Total Debits, Total Credits, and the Difference, and each group can be expanded to see the employees behind its total. The Finalize Payroll button stays disabled until every group is mapped.
Nothing is pre-selected simply to fill the form — a pre-filled account on both sides once let a self-cancelling journal be posted in one click, so the dialog opens with every account empty. The only thing offered is a remembered mapping from your last approved run, and only for groups you have not touched on this run. Every group is your explicit choice.
The mapping is remembered
The accounts you pick are stored per group and offered back the next time you post a run with the same groups. The suggestion applies only to groups you have not touched on this run, so it saves the repetitive work of a monthly payroll without ever silently changing something you set by hand.
One journal, two lines per group
It is worth being precise about the shape, because it decides what you will see in the ledger.
| Property | Value |
|---|---|
| How many journals | One, with its own journal number. |
| How many lines | Two per mapped pay-item group — one debit, one credit. |
| Journal date | The run's pay date — not the day you pressed Post. |
| Reference | `PAY-` followed by the run subject. |
| Line description | The group name, its type, and the employee count behind it. |
| Line amount | The group's total, which is the sum of amount × count across everyone carrying it. |
Payroll belongs to the period it paid, not to the afternoon somebody got round to posting it. Posting an August run in September still lands the cost in the month the pay date falls in.
What the journal looks like
The exact accounts are yours — the shape is always the same: earnings charged to expense, everything withheld sitting as a liability until it is paid over, and net pay owed to employees until the bank transfer goes out.
| Account | Debit | Credit | Description |
|---|---|---|---|
| Salary expense (your chosen debit account) | Gross for the salary group | — | The cost of employing people this period |
| Allowance expense | Total for each allowance group | — | One entry per allowance group you mapped |
| Tax payable (your chosen credit account) | — | Total tax withheld | Owed to the authority until you remit it |
| Deductions payable | — | Total of each deduction group | Loans, dues, recoveries — owed to whoever they are owed to |
| Net salaries payable | — | Total net pay | Owed to employees until the payment goes out |
The journal records what the business owes. The money moves when you pay it — from the bank file this run produces, or however else you disburse. Recording that payment clears the liability.
What the server refuses
The dialog is not the only thing standing between you and a bad posting. Every one of these is checked again on the server, so a stale screen cannot get past it.
| If… | What happens |
|---|---|
| The run is not a Draft | Refused. Only a draft can be finalized — which is what stops a run being posted twice. |
| A group names only one account | Refused, naming the group. |
| A group names the same account on both sides | Refused, naming the group. A self-cancelling journal is never posted. |
| Debits and credits do not agree | Refused. The journal must balance to the cent. |
The screen sends what each group totals; the server independently sums the run's own items (amount × count — the same figure the payslips show) and compares. A disagreement is recorded so it can be investigated, because the number in the journal and the number on the payslip must be the same number.
Before you post — a short checklist
- Needs attention is zero, or you know why it is not
- Not on this run contains only genuine leavers
- The largest entries in the Change column are ones you can explain
- Every group in the dialog is mapped, and the counter agrees
After posting
The run is Approved. From the workspace you can now:
- Send or download payslips
- Build the bank file that actually pays everyone
- Duplicate the run to start the next period