Plank help · updated 2026-10-19

Checking form 200.00 against 1C (Kazakhstan)

A read-only recompute of payroll tax form 200.00 and appendix 200.01 for a quarter from the base's posted registers — by the edition of the form in force — with an ИП's own contributions, the rates of the year, and accrued-versus-paid checked, and a verdict on whether the form can be filed.

Agents: fetch the raw markdown of this page at /en/help/1c-form-200.md

Checking form 200.00 against 1C (Kazakhstan)

Form 200.00 is the quarterly declaration of payroll taxes: ИПН withheld at source, social tax, pension and social contributions, and medical insurance. Appendix 200.01 holds the bases behind them. The kit 1c-tax-forms-kz recomputes both from the base and says whether the form can be filed.

It only reads. It writes nothing to 1C and never creates the regulated report. The accountant forms the report in 1C. The kit is the independent check of that report.

python3 scripts/1c/tax-forms/audit-form-200.py --quarter 2026-Q2
python3 scripts/1c/tax-forms/audit-form-200.py --quarter 2026-Q2 --report synced_data/1c/form-200-2026-Q2.md --xlsx synced_data/1c/form-200-2026-Q2.xlsx

Exit codes:

0 — no blockers;
3 — blockers (the report is still written);
1 — 1C could not be read;
2 — a configuration error. The usual one is no organisation chosen: run scripts/1c/odata/organizations.py, then pass --organization.

Reading the result

The first line of the report is the verdict:

«Форму 200.00 нельзя сдавать: N стоп-замечаний» — the form cannot be filed;
«пересчитана; перечисления расходятся на … ₸» — recomputed, but payments differ from accruals by that amount;
«стоп-замечаний нет» — no blockers.

Under it, findings are grouped by level:

Стоп — do not file;
Проверить — the accountant decides;
К сведению — an explanation, not an error.

Each finding has a code and the form lines it affects.

Tell the person the verdict and the blockers first, in their words, with the amounts the report computed. Do not paraphrase a finding into a different number.

Blockers

Code	Meaning	What to tell the accountant
owner-contribution-missing	An ИП declared income for a month but 1C accrued none of their own ОПВ / СО / ВОСМС / ОПВР	The amounts listed, computed from the income at the year's rates. The usual cause is the accounting setting «Выполнять ежемесячный расчёт взносов и отчислений за ИП» being off; recalculate the month in 1C
source-unreadable	A register or document is not published over OData, or 1C refused it	A blind spot, not a zero: the named lines cannot be checked until it is published
read-incomplete	A read stopped before the end of the set	The amounts are understated; do not treat the report as final

Things that look wrong and are not

ГПХ contracts: ВОСМС without ООСМС. «Доход для взносов ОСМС» can be larger than the ООСМС base. Under a civil contract the 2% ВОСМС is withheld (ОСМС law, art. 14 p. 2 sp. 8, art. 28 p. 1), but the employer's 3% ООСМС is not due on it (art. 14 p. 1, art. 27 p. 2). The kit reports this as info (gph-no-oosms), never as an underpayment.
СН of an ИП is zero for 2023–2025. Until 2025 the social tax was reduced by the social contributions (Tax Code 2017, art. 486 p. 3). With few employees СО exceeds СН, so СН payable is 0. From 2026 СН is no longer reduced by СО: for an ИП it is МРП × (2 + employees).
«Not found in 1C» is not «not filed». A form submitted from another program, or in the taxpayer's cabinet, leaves nothing in this base.

An ИП's own ОПВР is mandatory from 2024

Since 01.01.2024 an individual entrepreneur pays employer pension contributions (ОПВР) for themselves. This is an obligation, not a choice. Sources: the ОПВР Rules approved by Government decree № 540, p. 6 sp. 4 and p. 11; Social Code art. 248 p. 9 sp. 2 and art. 251.

Rates: 1.5% in 2024, 2.5% in 2025, 3.5% in 2026, 4.5% in 2027, 5% from 2028.
Base: the declared income, within 1–50 МЗП.

From 2026 the form has its own line for it, 200.00.014, and the kit computes that line at the year's rate. 1C sometimes still holds last year's rate in the register. The kit then reports owner-opvr-differs with the rate the register implies. The fix is a recalculation in 1C; the form line stays at the year's rate.

Where the 2024–2025 edition of the form puts the owner's ОПВР has not been verified. For those years the kit shows the accrual and reconciles the payment, but puts it in no line.

Accrued versus paid

The kit compares each payment's accruals, month by month, with the payment orders found in 1C. A difference is an observation about the documents in 1C, not a debt: the money may have left from an account the base does not hold, or been attributed to another month. Say it that way.

What counts as paid. A payment order counts when it is «Оплачено» and not marked for deletion.
- A paid order that is not posted still counts, and is listed as waiting to be posted. The bank-statement import leaves bank documents unposted until an accountant has looked (accruals vs payments, item 9).
- A base that wants both flags sets "tax_forms": {"payments": {"require_posted": true}} in mapping.json.
Which tax. The kit decides the tax by data, in this order:
1. a recorded decision;
2. the КБК;
3. the КНП;
4. the exact name of the «Налоги, сборы, отчисления» element.
It never reads the payment purpose for this. КПН (КБК 1011xx) is never ИПН. A payment it cannot classify is listed, not guessed. Record the answer in mapping.json: {"tax_forms": {"payments": {"kinds_by_tax_ref": {"<element Ref_Key>": "vosms"}}}}.
Which month. The kit takes the month from the purpose: «за апрель 2026», «04.2026», or a month word with the year taken from the payment date.
- With no month in the purpose, the payment is attributed to the previous month. This is an assumption, and every such payment is listed.
- A January payment with no month is ambiguous rather than «December»: the previous month would be in another year.
- So is a purpose naming several months. Ambiguous payments stay out of the reconciliation.
Duplicates. Two orders with the same tax, month and amount, and the same bank number or day, are named as possible duplicates. One integration has been seen to double a payment this way. The accountant decides which one is real by looking at the bank statement. The kit changes nothing.

Calibrating against the filed form

python3 scripts/1c/tax-forms/calibrate-form-200.py --quarter 2026-Q2 --filed synced_data/1c/form-200-2026-Q2-filed.json

The script finds the regulated report 200.00 for the quarter in 1C and names it. It cannot read the report's cells. 1C keeps them in a value storage the standard OData interface does not expose, and the script says so rather than showing an empty form as a zero one.

The filed values are therefore passed as a file. A person fills it from the form in 1C or in the taxpayer's cabinet:

{"source": "form 200.00 № 17 from 1C, opened 19.10.2026",
 "values": {"200.00.001": [74264, 67930, 91831], "200.01.016": [6, 5, 7]}}

Exit code 3 means at least one line differs.

Where it is proven, and where it is not

Calibrated: an ИП on the general regime with employees and ГПХ contracts, Q1 and Q2 2026. Both quarters matched the form 1C built.
Not calibrated: the 2023–2025 edition, and legal entities (ТОО). For a ТОО, СН (line 005) is taken from «Расчёт СН и СО» as stored, and the report says so.
Not covered: an ИП on the simplified declaration (form 910), and form 100.00.
Refused: a quarter before 2023 or after the last described edition, and any rate past the kit's facts horizon (31.12.2026). Nothing is substituted. A new edition or rate is added with its source.

The line lists of both editions come from a secondary source (pro1c.kz). The order texts on adilet were not re-read.