Document "IITWithholdingApplicationForDeductionGranting" — technical description

1. Identification

Purpose. The document registers applications of employees (individuals) for obtaining tax deductions on individual income tax (IIT) within the framework of the legislation of the Republic of Kazakhstan. It records the employer's obligation to grant a tax deduction linked to a specific type of deduction, period of validity and schedule of application by month. The registered planned deduction values are then used in payroll calculation and IIT computation.

The object's synonym is marked «(before 2018)» — historically the form was introduced for benefits of earlier periods. In current releases the document continues to be supplied and remains a working mechanism for storing planned deductions of individuals.

Where to find in 1C: section «Tax accounting» → «Application for granting an IIT deduction (before 2018)».

IIT calculation context (Kazakhstan, 2026). The document works together with the IIT computation mechanism, for which the following parameters apply in 2026:

• MCI = 4,325 ₸, MW = 85,000 ₸;
• basic IIT tax deduction = 30 MCI per month (= 129,750 ₸), but no more than 360 MCI per year (= 1,557,000 ₸);
• IIT rates: 10% on annual taxable income up to 8,500 MCI and 15% on the excess;
• MPC 10% (base ceiling 50 MW = 4,250,000 ₸), EPCR 3.5%, CHIC 2%, CHI 3%, SC 5%, social tax 6%.

This document adds additional planned deductions (contributions to the UAPF, education, mortgage, etc.) to the basic deduction, which reduce the IIT taxable base in the months specified in the schedule.

2. Header attributes and tabular sections

Header attributes

Posting rule: if at least one of the attributes ВычетИПН, ДатаНачала, ДатаОкончания, Организация, ФизЛицо is not filled in, 1C will not allow posting the document and will produce the error «Field … is not filled in».

Tabular section «PaymentSchedule»

Defines the distribution of the deduction amount by dates (months). Each row generates a record in the planned deductions register.

If the tabular section is empty, the document is posted without an error, but no records are generated (check Таблица.Количество() = 0 in the manager module).

Example of filling in the schedule (deduction for UAPF contributions, employee with a salary, monthly deduction amount 10,000 ₸):

3. Forms

A separate printed form for the document is generally not provided — the result is reflected in the IIT calculation documents, and not as a standalone form.

4. Key module procedures

Direct BSL code is not attached in the evidence, so below are the handlers typical for this type of object and the evidence-confirmed logic of record generation.

Object module (ObjectModule):

• ОбработкаПроведения(Отказ, РежимПроведения) — when РучнаяКорректировка = False iterates over the rows of ГрафикПлатежей and generates records for the register ИПНПлановыеНалоговыеВычетыФизлиц; when РучнаяКорректировка = True auto-filling of records is not performed (records remain as set manually).
• ОбработкаЗаполнения(ДанныеЗаполнения) — filling of attributes when entering based on / copying.
• ПроверкаЗаполнения(Отказ, ПроверяемыеРеквизиты) — control of mandatory attributes (ВычетИПН, ДатаНачала, ДатаОкончания, Организация, ФизЛицо) and the ДатаПлатежа column of the tabular section.

Manager module (ManagerModule):

• Procedures for generating records with the check Таблица.Количество() = 0 — with an empty schedule no records are created.
• Batch processing procedures (see scenario 3.4 «Batch change of documents» — mass extension of deductions).

Form module (FormModule):

• ПриСозданииНаСервере, ПередЗаписью, handlers of changes to ВычетИПН/ДатаНачала/ДатаОкончания and events of the ГрафикПлатежей tabular section (filling of amounts and dates in manual mode).

5. Posting and records

Records register: InformationRegister.ИПНПлановыеНалоговыеВычетыФизлиц (information register).

Conditions for generating records:

1. РучнаяКорректировка = False;
2. the tabular section ГрафикПлатежей is filled in (otherwise the document is posted, but there are no records).

For each row of «PaymentSchedule» a record is created:

What is important to understand about this document:

• It is a registrar of planned data, not a document of business operations. It does not generate accounting entries on the accounts of the Standard chart of accounts of the RK (1210, 1030, 1330, 3310, 3130, 6010, 7010) and does not move through the accounting register.
• The actual reduction of the taxable base and the IIT calculation are performed in the payroll accrual documents, which read the planned deductions from the register ИПНПлановыеНалоговыеВычетыФизлиц.

Example of impact on IIT (2026). Employee, monthly taxable income after MPC and CHIC — 300,000 ₸.

• Basic IIT deduction: 30 MCI = 129,750 ₸.
• Additional planned deduction from this document (for example, UAPF): 10,000 ₸.
• IIT taxable base: 300,000 − 129,750 − 10,000 = 160,250 ₸.
• IIT at the rate of 10%: 160,250 × 10% = 16,025 ₸.

Without the application document (only the basic deduction) the base would be 170,250 ₸, and the IIT — 17,025 ₸. The difference of 1,000 ₸ is the direct effect of the planned deduction in this month.

6. Related objects and entry based on

Entry based on. The typical scenario is extension of a valid deduction (3.2): a new application is created by copying / based on a previously issued one, with a shift of the ДатаНачала/ДатаОкончания period and re-filling of the schedule for the new year.

7. Extension points

• Object module → ОбработкаПроведения — adding your own analytics to the register records or additional schedule checks (for example, control of the annual deduction limit).
• ПроверкаЗаполнения — extension of validation rules (correspondence of schedule dates to the ДатаНачала–ДатаОкончания period, control of duplicates by individual and deduction type).
• Form module — auto-filling of ГрафикПлатежей by period (even distribution of the amount over months), hints by deduction type.
• Batch processing (ManagerModule) — implementation of mass extension of deductions for a new year (scenario 3.4).
• Electronic document exchange — the document itself does not participate in the exchange of ESF/SNT (IS ESF); extensions here are inappropriate (this is tax accounting for individuals, not the sale of inventory).

Requires verification (version-specific): the exact composition of the dimensions of the register ИПНПлановыеНалоговыеВычетыФизлиц (the presence of the СтруктурноеПодразделение dimension depends on the enabled functional option) and the presence of batch processing procedures in the specific build 3.0.74.2. The rest of the logic is stable between releases.