Monthly payroll accrual in 1C (Kazakhstan)

One month of payroll, for one organisation, is four documents — not one, and not one per employee. Each covers all the employees in the period.

Зарплата к выплате is the payment step. It is not one of the four, and it is created only when the money actually moves.

There is a kit for this: install 1c-payroll-kz (see the 1C starter kit). The rules below are what it enforces.

They are not linked to each other, and that is normal

There is no ДокументОснование between these four. Do not look for one, and do not create one. In this configuration they are tied only by:

• the organisation,
• ПериодРегистрации — the accrual month,
• the individual (Catalog_ФизическиеЛица),
• and amounts that agree because someone made them agree.

Two consequences, and both are load-bearing:

Changing the accrual changes nothing downstream. Edit document 1 and documents 2, 3 and 4 keep the old numbers, silently, with no recalculation and no warning. If you amend an accrual, every later document in that month is now suspect and has to be re-read against it.

The duplicate guard cannot use a basis link. Recognise an existing document by organisation + ПериодРегистрации month + document kind, then by whether the individual already has rows in it. A second «Расчет СН и СО» for the same month is not a second opinion; it is double the taxes.

What you need before you start

• the organisation and the base — see OData rules §2.5;
• the employee and their ФизическоеЛицо;
• the accrual month;
• the kind of accrual: salary, vacation pay, compensation — they are not the same row;
• the amount;
• working days and hours from the official production calendar for that month;
• time actually worked, and any absences;
• the current rates, caps, deductions and exemptions;
• the subdivision and the reflection method;
• the confirmed expense item (see below).

If any of these is missing, that employee stops. Not the run — that employee.

Find a comparable posted chain first

Read a posted chain for the same organisation in the same base, ideally the previous month, and use it for shape: which rows exist, which fields are filled, which references are used. Names confirm that you found the right template; the references you write must still come from this base.

Then read the whole target period before writing anything, and exclude duplicates by organisation, month, individual and kind.

The amounts are not last month's amounts

Copying the previous month's row is the technique — and it is where the money goes wrong. The shape is stable across months. The numbers are not:

• rates, caps and thresholds change, sometimes mid-year;
• the taxable base follows this month's accrual, not last month's;
• deductions and exemptions can start or stop for one employee;
• the production calendar differs every month, so days and hours differ;
• a zero row is legitimate only with a confirmed reason. A leftover zero row copied from a template is not a reason.

Set the tax-period month on every row, not only in the header. A row carrying last month's tax period is a correct amount filed against the wrong month.

«Статья расходов» is mandatory, and its absence is silent

In the reflection document, every applicable row must carry an expense item. Leaving it empty is not an omission the configuration will catch for you.

This is the defect that reached a real accountant on 2026-08-04: the drafts were built, the amounts were right, the accounts were right, and the expense item was empty. Nothing failed. The document read as finished.

• Take the item from a posted comparable document of this same company. It is frequently «Заработная плата», but the name is a hint and the reference is the answer — confirm it in this base.
• If the configuration keeps both accounting and tax analytics, fill it in both.
• An empty expense item is a stop, not a warning. The kit refuses to write the reflection document without one.

Check the rest of each posting too: debit account, expense item, subdivision, credit account, calculation kind, individual and amount.

The reflection total is larger than the payroll, and should be

The reflection covers accrual plus withholdings plus employer contributions. A reflection that sums to the net salary is missing rows; a reflection that sums to the gross accrual alone is missing the employer side.

The number to check it against is the sum of the rows you prepared across documents 1–3 — not the salary, and not the payment.

Writing

• Drafts only: Posted = false, DeletionMark = false, with a comment.
• Tabular sections go inside the parent document's POST.
• Re-check for a duplicate immediately before each write.
• After each write, re-read from 1C and verify: status, ПериодРегистрации, the individual, row count, amounts, taxable bases, accounts, and the expense item.
• A second run must recognise what the first one created and add nothing.

Amending, and when to stop

• Amend an unposted document only after re-reading it and confirming it is one this process created.
• Send every row you intend to keep. A partial tabular section replaces the section — the rows you left out are deleted.
• If 1C rejects the change, do not create a corrected copy next to the wrong document. Two payroll documents for one month is worse than one wrong one. Stop, report the document number and the correction needed, and let the accountant fix it in 1C.
• Never edit or un-post a posted document.

Final check, per employee

• the accrual matches time worked and absences;
• withholdings are computed from the right base;
• employer contributions are computed from the right base;
• the reflection has every row it needs and a filled expense item on each;
• organisation, period and individual agree across all four documents;
• every document has the status you expect;
• there are no duplicates;
• Зарплата к выплате exists only if it was actually required.

Posting

Only on a separate, explicit instruction from the user, and only after the whole chain has been checked.

Afterwards

Whether the money actually left the account is a different question, answered by a different, read-only procedure: checking payroll accruals against payments.