Checking payroll accruals against payments in 1C

Month by month, for one organisation, this check establishes four things:

1. how much income and tax was accrued;
2. how much was actually paid to employees;
3. how much was actually transferred to the budget and the funds;
4. where there is a discrepancy, an unconfirmed payment, or data you could not read.

It is read-only and changes nothing in 1C. Every finding is an observation about documents that already exist. If the check concludes that something must be paid or corrected, that is a sentence in the report, not an action.

The deliverable is two things, and the second is not optional: a table per month, and a list of what you could not verify. An audit that omits its blind spots reads as a clean bill of health.

What it does not establish. This is a per-month coverage check, not a settlement balance. It carries no opening balance, no overpayment brought forward from an earlier period, and no refunds or offsets. A month that balances does not mean the company is square with the budget, and a month that does not balance may already be covered by an overpayment of that same tax in an earlier month. Say which one you are claiming; never quietly extend a monthly delta into a verdict on the account.

This procedure carries no company in it

It applies to any 1C base. The organisation, the period, the catalog references and the set of published OData objects are established again in every base — see OData rules §2.5. Use only the credentials of the current space, and never carry an organisation, БИН/ИИН, bank account or GUID in from another base or another workspace's notes.

What you read

• posted documents: Начисление зарплаты, Расчет удержаний, Расчет СН и СО;
• the registers of income by ИПН, ОПВ, ОПВР, СО, ОСМС and ВОСМС — confirm in $metadata whether this configuration publishes them as InformationRegister_* or AccumulationRegister_*. Guessing the wrong kind returns nothing, which reads exactly like nothing was accrued;
• registers of settlements with the budget and the funds, row type Исчисление;
• the register of income actually paid to employees;
• payment orders and payment slips — Платежное поручение, Платежный ордер — that are Оплачено (see step 9 for why Проведен is not the test);
• зарплатные ведомости and lists of individuals, where those are published.

Object names differ between configurations. Check $metadata first (OData rules §4).

An object that is not published is not a zero. If it is missing, write не могу проверить against that line and carry it into the limitations section. A register you could not read produces an empty cell that looks exactly like "nothing was accrued".

The procedure

1. Use only the current space's credentials, and establish which organisation you are working in inside this base.
2. Fix the period under review and build the list of months. Never mix organisations in one list — one base often holds several.
3. Read every candidate document, then count only the active, posted, not marked-for-deletion ones in the accrual totals. A draft is not an accrual — but it is a finding, and step 14 is where it goes. Filtering drafts out at the query is how a report ends up unable to mention the ones that exist. This rule is about the accrual side only. Payment documents are judged by Оплачено, not by posting — see step 9, and do not apply this step to them.
4. Collect accrued income per month and per employee, and the withholdings taken from it, so you have both the gross accrual and the net payable — the figure the payment is supposed to settle.
5. Collect income actually paid, per month, per employee and per ведомость.
6. Collect accrued ИПН, ОПВ, ОПВР, СО, социальный налог, отчисления ОСМС, взносы ОСМС — and ОППВ where this organisation owes it — separately. One line per payment kind, never a combined total: they go to different recipients and are reconciled separately.
7. Take each amount from one source and corroborate it with the other — never sum both. A posted document and the register movements it produced are the same obligation seen twice. Decide which is authoritative for the figure (the register is usually the safer total, since it is what the configuration actually computed), and use the other to confirm it. Disagreement between them is a finding.
8. Keep employees, ГПХ contracts and ИП «за себя» apart. These categories cannot be offset against one another without a proven basis.
9. Confirm a transfer with Оплачено = true — that is what says the operation is in the bank statement. Проведен is an accounting state, not proof the money moved: our own import workflow leaves bank-derived documents unposted on purpose until an accountant reviews them (bank statement import §1). So a paid-but-unposted payment counts as a confirmed transfer and goes into the limitations list as awaiting posting. Requiring both statuses is how a real payment becomes an imaginary tax debt. A posted order that is not Оплачено is the opposite case — an intention, and it does not count. DeletionMark = true still excludes a payment, posted or not: dropping the posting condition does not drop that one, and a paid document someone marked for deletion is usually the erroneous half of a re-import.
10. Exclude пени from the main taxes and give them their own rows, one per tax. Пеня folded into the tax makes an underpayment look covered, and a single combined пеня row lets one tax's penalty hide another's.
11. Determine which tax a payment is, from ВидНалога_Key and the КБК of the catalogue element it points at — never from КНП alone. Different taxes share a КНП: withholding income tax and social tax both commonly arrive under КНП 911, and only the КБК separates them. Getting this wrong does not lose a payment, it files it on the wrong row, so one tax reads overpaid and another unpaid. See bank statement import §10.
12. Determine the tax month from the payment purpose and the related lists. If the month is not stated, attribute the payment to the previous month only when the operation kind, the amount and the related documents all agree. Otherwise mark the period as unconfirmed.
13. Check for duplicates by organisation, payment kind, tax month, amount, operation date and the bank document number — НомерВходящегоДокумента, not 1C's own Number. Two imports of the same statement line get two different internal numbers, so a signature built on Number never matches and counts the payment twice. See OData rules §6.
14. Re-read the final documents and registers before issuing the report, and assemble the limitations list: unposted documents, unpublished objects, and every period you marked unconfirmed.

Step 12 quietly decides a large part of the table. A payment with no month in its назначение платежа is genuinely ambiguous, and guessing it into the convenient month is how a check produces a balanced table for a company that is behind.

The table

For each month:

Разница = перечислено − начислено. A negative figure means the accrual is not covered by transfers confirmed in 1C — which is a different claim from "unpaid", and the wording matters (see below).

The salary row is «к выплате», not the gross accrual. What a payment settles is the net payable — gross accrual minus the withholdings. Put that in «Начислено» and the row reconciles: zero means the payable was settled, and a negative difference is a shortfall against the payments confirmed in 1C — the same qualified claim as every other row, not a finding that employees were underpaid. Comparing the gross accrual with cash paid instead guarantees a negative number every month, and it double-counts, because ИПН, ОПВ and ВОСМС already have rows of their own. Report the gross figure alongside for context — it is the base the tax rows are computed from — but never in this row's «Начислено».

Keep every row even when it is zero. A row you dropped because it was empty is indistinguishable from one you never looked at. Отчисления ОСМС (employer) and Взносы ОСМС (withheld from the employee) are two different payments and never share a row.

The rows above are the floor, not the ceiling. Add one for anything else this organisation actually owes, and drop ОППВ only once you have established it does not. Penalties get one row per tax (Пени: ИПН, Пени: ОПВ, …): a single combined пеня row lets an overpaid penalty on one tax hide a shortfall on another — the same netting the rules below forbid everywhere else.

Пеня usually has no accrual document in 1C. When there is nothing that accrued it, its «Начислено» cell is не могу проверить, not 0: a zero would assert that nothing was owed, and you have not established that. The payment is not proof of the liability either — it does not tell you the correct amount or which month it belongs to, so report it as paid and the accrual as unverifiable, and leave the arithmetic to whoever has the tax authority's figure.

Cite the source in the last column — the document or register the figure came from. A number without a source cannot be re-checked by the accountant who has to act on it.

What you may not say

• Do not call a sum a bank debt because you did not find the payment in 1C. Write перечисление не подтверждено в 1С. The absence of a document in 1C is a fact about 1C, not about the company's bank account.
• Do not read a quarterly salary difference as a debt without reconciling per employee, per ведомость and per accrual period. A payment can legitimately belong to a different month than the accrual it settles.
• Do not cover an underpayment of one tax with an overpayment of another. Each row stands alone. They are different recipients; a net-zero total is not a settled obligation.
• For every discrepancy give the month, the payment kind, the amount and the source documents.
• Do not turn a monthly delta into a verdict on the account. An arrear brought forward is still owed even when this month balances; an overpayment of the same tax in an earlier month can legitimately cover this one. Neither is visible in this table, so both are things to say, not things to assume.
• List separately: unposted documents, OData objects that are missing, and any other limit on what the check could see.
• Keep three things visibly apart — verified facts, computed assumptions, and actions you are merely proposing. A proposal that reads as a finding is how an accountant ends up paying twice.

Saving the result

The result of a specific check goes into a report file in the current space (see deliverables). Company names, БИН/ИИН, bank accounts, GUIDs and operation history live in that report and nowhere else — not in this shared procedure, and not in another space's notes.

Related

• Monthly payroll accrual — creating the four documents this check reads.
• Working with 1C over OData — the mechanics, including how to tell "not published" from "not there".
• Importing a bank statement into 1C — §10 is how a tax payment identifies its tax, which is what puts it on the right row here.
• The 1C starter kit — 1c-payroll-kz's check-payroll.py audits the chain's completeness and its expense items; it does not reconcile accruals against payments.