--- title: "Guide \"Accounting Audit Rules\" - Technical Description (Accounting for Kazakhstan 3.0.74.2)" country: KZ lang: en author: Сапа Т.И. (https://buhgpt.kz/authors/sapa-ti) date: 2026-09-07 canonical: https://buhgpt.kz/suraqtar/spravochnik-pravilaproverkiucheta-tehnicheskoe-opisanie-b-en source: BuhGPT --- # Guide "Accounting Audit Rules" - Technical Description (Accounting for Kazakhstan 3.0.74.2) > **TL;DR:** 1. Identification Parameter Value Object Type Catalog Name AccountingCheckRules Full Name Catalog.AccountingCheckRules ( Catalogs.AccountingCheckRules ) Synonym Accounting check rules Configuration Accounting for Kazakhstan, edition 3.0.74.2 Subsystem Accounting control (Stand --- 1. Identification Parameter Value Object Type Catalog Name AccountingCheckRules Full Name Catalog.AccountingCheckRules (Catalogs.AccountingCheckRules) Synonym Accounting check rules Configuration Accounting for Kazakhstan, edition 3.0.74.2 Subsystem Accounting control (Standard subsystems) Navigation Link e1cib/list/Catalog.AccountingCheckRules Purpose. The catalog stores a list of rules (checks) for the correctness of accounting. Each element describes a specific situation to be checked: the essence of the problem, its criticality, causes of occurrence, recommendations for resolution, and parameters for automatic execution (launch method, schedule, limits, start date of analysis). The system uses these rules to automatically identify errors and discrepancies in accounting data (for example, negative balances on account 1330 "Goods", unclosed advances on 1210/3310, VAT discrepancies on account 3130, absence of electronic invoices (ESF) for sales with movements on 6010/1210). The catalog is a dictionary of control settings, not a document: it does not generate movements in registers, but sets metadata for the accounting check mechanism. Work with it is carried out during initial setup and periodically — when requirements for control change or after configuration updates. Where to find: section "Standard subsystems" → "Accounting check rules" (or directly via the navigation link e1cib/list/Catalog.AccountingCheckRules). 2. Header Attributes and Table Parts 2.1 Header Attributes Name Type Mandatory Purpose ProblemCriticality EnumerationReference.ProblemCriticality Mandatory (ShowError) Criticality of the identified problem ("Critical", "Important", "Informational"). Affects the priority of resolution and visual highlighting in the reports of the check results. Identifier String Optional Unique program code of the rule for linking with configuration metadata and handler procedures. Used during configuration updates to synchronize the predefined set of rules. Usage Boolean Optional Activity flag: True — check is performed, False — disabled. Automatically reset to False when the item is marked for deletion. Causes String (unlimited) Optional Text description of the causes of the problem. Used for user training and documenting the logic of the check. Recommendation String (unlimited) Optional Recommendations for resolving the problem. Displayed to the user along with the check results. ExecutionMethod EnumerationReference.ExecutionMethods Optional How the check is initiated: by schedule (regulatory task), on user demand, automatically when processing documents, etc. RegulatoryTaskIdentifier String Optional Identifier of the regulatory task when automatically executed by schedule. Links the rule with the background task. AdditionalParameters ValueStorage Optional Arbitrary structure of specific check parameters (filters, threshold values, algorithm settings). CheckStartDate Date (DateTime) Optional Initial date for data analysis. Allows exclusion of historical periods from the check. ProblemLimit Number (decimal) Optional Maximum number of problems identified in one run. Limits execution time and volume of results. CheckExecutionSchedule ValueStorage Optional Serialized schedule object (TaskScheduler) defining the frequency of auto-start for the regulatory task. In addition to the listed attributes, the element has standard catalog attributes: Code, Name, DeletionMark, Predefined. Typically, the catalog is not hierarchical and contains a predefined set of rules supplied with the configuration. 2.2 Table Parts In the attached evidence, table parts are not recorded. For a catalog of this purpose, additional check parameters (filters, thresholds, list of controlled accounts/objects) are stored not in table parts, but in attributes of type ValueStorage (AdditionalParameters, CheckExecutionSchedule). The presence/absence of table parts is version-specific and is clarified in the configurator of the specific version. 3. Forms Form Purpose ListForm Main list of rules. Displays the name, problem criticality, and usage flag; allows enabling/disabling rules, opening elements, and running checks on selected rules. ElementForm Rule card: editing criticality, identifier, causes, recommendations, execution method, start date, problem limit, and regulatory task schedule settings. SelectionForm Selecting a rule from other configuration objects (for example, when setting up groups of checks or when programmatically accessing a rule). The exact composition of forms depends on the version; in the absence of explicitly defined forms, the platform uses auto-generated list/element/selection forms. 4. Key Procedures of Modules In the attached evidence, the text of the modules (BSL) is not provided. Below are typical handlers for a catalog of this type; specific lines should be viewed in the modules of the object/form of the corresponding version. Object Module (BeforeWriting, BeforeCopying): - BeforeWriting — control of filling the mandatory attribute ProblemCriticality; synchronization of the Usage flag with DeletionMark (when setting the deletion mark Usage → False). - CheckFillingHandler — check of filling ProblemCriticality (ShowError) and, when ExecutionMethod = BySchedule, requirement for filled CheckExecutionSchedule. Manager Module / Common Modules of the Control Subsystem: - Procedures for obtaining active rules (Usage = True) and launching the associated accounting check mechanism. - Registration/updating of the regulatory task by RegulatoryTaskIdentifier and CheckExecutionSchedule. - Formation of check results considering ProblemLimit, CheckStartDate, and parameters from AdditionalParameters. Element Form Module: - OnCreateOnServer / OnReadOnServer — restoration of schedule settings from ValueStorage for display in the schedule control element. - Handlers for visibility/accessibility of schedule fields depending on the value of ExecutionMethod. 5. Processing and Movements The catalog is not a document and is not processed — it does not generate accounting entries and movements in accumulation/summary registers. Its role is to store check settings. Movements in accounting registers are generated by documents, and the rules from this catalog only analyze the results of such accounting. Typical checks configured through the catalog are oriented towards the chart of accounts of the RK, for example: - Negative balances of inventory — control of debit/credit balance on account 1330 "Goods". - Unclosed settlements and advances — analysis of 1210 "Short-term accounts receivable from customers" and 3310 "Short-term accounts payable to suppliers". - VAT control — reconciliation of turnover and balance on 3130 "VAT payable" (the VAT rate in Kazakhstan from 2026 is 16%) with the register of issued/received ESF (IS ESF) and issued СНТ. - Completeness of sales reflection — comparison of income on 6010 "Income from sales" and written-off cost 7010 "Cost of sales" with the presence of issued ESF. - Cash flow — control of the correctness of entries on 1030 "Cash in current bank accounts". The results of rule execution are saved by the accounting control mechanism (journal/register of check results of the "Accounting control" subsystem), not by the catalog itself. 6. Related Objects and Input Based On Enumerations (attribute types): - Enumeration.ProblemCriticality — levels of criticality. - Enumeration.ExecutionMethods — methods of initiation. Platform/BSP Mechanisms: - Regulatory tasks (RegulatoryTask, TaskScheduler) — by RegulatoryTaskIdentifier and CheckExecutionSchedule. - Subsystem "Accounting control" — consumer of rules; forms and stores the results of checks. Analyzed accounting objects (indirect link through check algorithms): sales/purchase documents, payment documents, accounting register (chart of accounts of the RK), electronic documents ESF and СНТ. Input Based On. For the catalog, input based on is not provided and does not make sense: elements are created manually or supplied as predefined data of the configuration. 7. Extension Points - Custom check rules. Creating new catalog elements by filling in Identifier, Causes, Recommendation, and launch parameters; linking to a custom check algorithm through AdditionalParameters. - Configuration extension (Extensions). Adding attributes/forms, overriding handlers BeforeWriting, CheckFillingHandler without removing the configuration from support. - Schedule settings. Changing ExecutionMethod and CheckExecutionSchedule to fit the enterprise regulations (for example, monthly VAT control before generating ESF). - Parameterization through AdditionalParameters. Storing threshold values and filters (list of controlled accounts, minimum amounts, organizations) without changing the metadata structure. - Localization of texts. Maintaining Causes/Recommendation under the requirements of the RK with indication of current norms for 2026 (VAT 16%, MRP 4,325 ₸, MZP 85,000 ₸). Version-specific: the specific composition of predefined rules and the list of available values for enumerations ProblemCriticality/ExecutionMethods is clarified in the configurator of version 3.0.74.2. --- _BuhGPT — ИИ-помощник для бухгалтеров Казахстана: https://buhgpt.kz_