Checking the VAT rate in a 1C base

Kazakhstan replaced its Tax Code on 2026-01-01 and the standard VAT rate went 12% → 16% (ст. 503 п.1 НК РК от 18.07.2025 № 214-VIII, in force from that day by ст. 848 п.1; the previous 12% was ст. 422 п.1 НК РК от 25.12.2017 № 120-VI, repealed the same day).

Run the report:

python3 scripts/1c/odata/audit-vat-rate.py
python3 scripts/1c/odata/audit-vat-rate.py --since 2026-01-01
python3 scripts/1c/odata/audit-vat-rate.py --entity-set Document_ЭСФ
python3 scripts/1c/odata/audit-vat-rate.py --check-facts   # no base, no credentials

It writes nothing. Not to 1C, not to the mapping, not to what the next import does. It reads documents the base already holds and names the ones whose rate disagrees with the statute for the date their turnover happened. Deciding what to do about a finding is the accountant's, and this page does not tell you to change anything.

The rate follows the turnover date, not the document date

This is the whole difficulty, and getting it wrong is how a report becomes useless.

The rate that applies is the one in force on the дата совершения оборота (ст. 460), not on the day somebody typed the document. ст. 465 п.2 says it in as many words: «с применением ставки налога на добавленную стоимость, действовавшей на дату совершения оборота по реализации».

So a base settling its 2025 receivables in 2026 lawfully holds both rates, for as long as that takes. A 12% document dated March 2026 is not evidence of anything on its own.

Two consequences worth stating before you reason about any base:

• No recall window can decide this. Most-recent, plurality and unanimous all fail — not just most-recent. You cannot ask the base what its rate «is».
• A lag is usually not a lag. One pilot base looked six months behind; it had in fact applied 16% from January, and its 12% documents were payments closing 2025 invoices. Every base that books a standard rate at all had its first 16% document in 2026-01 or 2026-02.

The four cases where the old rate is lawful

Comparing dates against rates naively produces 2 405 findings across 14 bases, of which roughly 1 700 are lawful or unprovable. Four exclusions cut that by 74%, and they are the report's actual specification:

1. A payment whose underlying supply date is invisible. A 2026 transfer may be settling a 2025 invoice, and from outside the base the invoice is a reference, not a date. (1 626 documents, 23,9 M ₸ — the largest bucket by far.)
2. Anything declaring a pre-change turnover date — including an invoice issued inside the fifteen days ст. 493 п.1 allows after the turnover, and a corrected or supplementary invoice, which inherit the original's rate (ст. 499, ст. 500).
3. A return of a pre-change sale — the correction follows the original turnover (ст. 464 п.2).
4. A rate set with СуммаНДС = 0 — an empty analytic, no tenge either way.

They are applied in that order and the first match owns the document, so the buckets sum to the population. The order decides only which bucket a document is counted in; a document matching any of them is excluded either way.

Two populations, printed apart

Provable. A supply document — a realisation, a receipt, an act — happens on its own date, and a document that declares its turnover date says so outright. Here the governing date is known and a disagreement is a fact.

Indicated. A customer payment naming no earlier document has nothing behind it to settle: no deal, no basis, no invoice, so the only date it has is its own. That is strong and it is not proof, which is why these are listed under their own heading with the base's own behaviour printed beside them — how many months the old rate keeps appearing in, and how many documents the same base booked at the statutory rate over the same period.

That comparison is the point. One stale default firing 584 times reads very differently from a base that simply has not switched over yet, and the difference is visible nowhere else.

Why this is a report and not a correction

The proposal behind this tool was that the kit was booking the old rate and needed fixing. The measurement said otherwise.

Across 14 reachable bases and 126 029 posted documents: 2 405 documents disagree with the statutory rate, and 3 of them were written by the kit — all three at 0,00 ₸. The kit's entire exposure to a stale rate is zero tenge.

The same scan found 627 accountant-authored documents worth 7 722 433 ₸ that nobody had noticed, 584 of them in a single base — card takings at 12% in every month of 2026, while that same base booked 16% freely on 477 other documents. One channel never moved, and nothing was looking at it.

So: the dated fact is a small enabling piece, and the report is the product.

Keeping the dated facts honest

The rates live in scripts/1c/legal/kz-facts.json with the article and date behind each one. --check-facts validates that file and reports anything nobody has re-verified lately — it needs no base and no credentials, and it is how the next 1 January gets noticed rather than discovered in somebody's books.

Past the file's horizon the answer is beyond_horizon with no percentage, not a guess carried forward. A date the file cannot speak to produces no finding.

Cite the act, never a mirror. Every rate, date and article here was read from old.adilet.zan.kz directly (acts K2500000214 and K1700000120). A summariser reading a popular mirror asserted «ст. 503 — 12%», which is false.

Reading the exit code

A 0 is only meaningful alongside a complete read — an incomplete scan exits 1 precisely so that «no findings» can never mean «I could not look».

Cost

The scan is a full read of every VAT-bearing document type the base publishes, because the finding that motivates the whole report sits in a document type no mapping in this repo names. Expect minutes on a large base, and narrow it with --entity-set when you already know where to look.