Document "EPRefundPayment" (Unified Payment - Refund from Funds/Budget) - Accounting for Kazakhstan 3.0.74.2

1. Identification of the Object

Purpose. The document registers the refund of the unified payment (EP) from state funds and the budget of the Republic of Kazakhstan to the organization. The unified payment is a consolidated mandatory payment from the wage fund, combining individual income tax (IIT), pension contributions (PC), social contributions (SC), and social tax, which is paid to the budget in one sum through the operator (Government for Citizens). The document “EPRefundPayment” records the situation when previously transferred amounts (according to the document EPPaymentToFunds) are returned to the organization: in case of overpayment, recalculation, erroneous transfer, or by the fund's order.

The document is used by accountants and payroll specialists. It contains a breakdown of the refunded amounts by individuals (employees) and tax periods, which is necessary for the correct restoration of personalized accounting data.

All rates and norms in the examples below are as of 2026: VAT 16%, MRP = 4,325 ₸, MSP = 85,000 ₸, basic tax deduction for IIT = 30 MRP/month (not more than 360 MRP/year), IIT 10% (15% over 8,500 MRP annual income), PC 10% (base ceiling 50 MSP), SC 3.5%, social contributions 2%, social tax 6%.

2. Header Attributes and Table Parts

2.1 Header Attributes

Mandatory attributes for processing: Organization, RegistrationPeriod. If the field is not filled, 1C will not process the document and will issue an error “Field … is not filled”.

2.2 Table Part “UnifiedPayments”

Main table part with line-by-line detail of the refund by individuals.

Mandatory columns for processing in the table part: Individual, TaxPeriodMonth.

3. Forms

In the absence of explicitly defined forms, the platform uses automatically generated document and list forms based on the structure of attributes.

4. Key Module Procedures

The attached evidence does not provide the source code (BSL) of the modules. Below are standard handlers for documents of this type in 1C configurations on managed forms. Exact names and presence of procedures are confirmed in the specific release.

Object Module

• ProcessingProcedure(Refusal, ProcessingMode) — for this document, the body is actually empty (no movements are generated, see section 5). If necessary, it may only perform checks.
• FillingProcedure(FillingData, FillingText, StandardProcessing) — filling when entering based on EPPaymentToFunds: transferring organization, period, basis document, and list of individuals with amounts.
• FillingCheckProcedure(Refusal, CheckedAttributes) — control of mandatory fields (Organization, RegistrationPeriod, Individual, TaxPeriodMonth).
• BeforeSaving(Refusal, SavingMode, ProcessingMode) — recalculation of the total amount, service checks.

Form Module

• OnCreateOnServer(Refusal, StandardProcessing) — initial form initialization, setting conditional formatting and visibility.
• FillByBasis() (command) — filling the table part based on the selected payment document.
• UnifiedPaymentsIndividualOnChange(Element) — handling changes to the individual in the line (substituting data).
• FillingCheckHandlers on the form — interactive validation.

5. Processing and Movements

The document does not generate movements in the registers. In the metadata, the set of registrars (register_records) is empty.

EPRefundPayment is an informational basis document. It records the fact and detail of the refund (by individuals and periods), but does not itself create accounting entries and records in the calculation/accumulation registers does not create. The data of the document is used by other documents (for example, documents for accounting cash and settlements with the budget) to form entries.

How the refund is reflected in accounting (according to the standard chart of accounts of the RK)

The actual receipt of refunded funds and adjustment of settlements with the budget/funds are reflected by accompanying documents. According to the standard chart of accounts of the RK, the movement looks like this:

Specific accounts for settlements for each component of EP are determined by the accounting account settings in the configuration; the document “EPRefundPayment” does not make entries.

6. Related Objects and Input Based on

Main Scenarios

1. Creating a refund based on a payment to funds — the fund returns previously transferred amounts; the document is entered based on EPPaymentToFunds.
2. Manual filling by employee list — refund by the fund's order/accounting note without a specific basis document.
3. Adjustment of the created refund — correction of amounts or composition of employees after recording.
4. Changing the basis document — reissuing the refund to another payment document.
5. Group change — mass change of attributes (Responsible, Comment) for several documents through the “Group Change of Attributes” processing.

7. Extension Points

• Configuration extension: adding header/table part attributes, additional columns of detail by components of EP without removing from support.
• Object module handlers: BeforeSaving, FillingCheckProcedure, FillingProcedure — for custom logic of auto-filling and validation.
• Event subscriptions (EventSubscription) — intercepting ProcessingProcedure/OnSaving, for example, for integration with external refund accounting logic.
• Additional attributes and information (BSP mechanism) — extending analytics without changing metadata.
• Exchange/export rules — including the document in exchange plans when integrating with external systems.

Version-specific (requires verification in the specific release 3.0.74.2): the exact composition of detail columns by components of EP and the presence/body of the procedure ProcessingProcedure — as the object is classified as informational and does not generate movements.