“Prepayment” for a Few Kopecks in a pECR Receipt: How to Find the Cause of Rounding

«Prepayment» for a few kopecks in a pECR receipt: how to find the cause of rounding and DocumentValidationError

In sales involving invoices, a customer may make a deposit, pay for an order in installments, or make the final payment upon receiving the goods. The pECR must reflect each stage of the payment and link the final receipt to the previously fiscalized prepayment. Business owners ask specialists why a «Prepayment» line for UAH 0.01–0.59 appears on the receipt even though no new prepayment was made, why the State Tax Service rejects the document with DocumentValidationError, whether cash rounding affected it, how the payment was distributed between two Sole Proprietorships, and which specific document should be checked. The answer depends on the stage at which the discrepancy occurred: in the original invoice, the previous fiscal receipt, the current payment document, the rounding settings, or the distribution of the sale between businesses.

Basic concepts and current situation

A prepayment is an amount paid by the customer before the goods are fully transferred or the payment is completed. In Torgsoft, it can be recorded simultaneously:

• in the order document or sales invoice;

• in the payment financial document;

• in the pECR fiscal receipt;

• in the details of the subsequent payment or final settlement.

Fiscalized prepayment is not merely a record of debt or movement of funds in the software, but a payment transaction whose receipt has been registered on the fiscal server of the State Tax Service.

Subsequent payment is the next part of the payment for the same order. The final settlement closes the remaining balance under the document, taking into account previously received payments.

DocumentValidationError, or code 9 in the pECR response, is a general document validation failure. What matters is not only the code, but the entire text that follows it. For example, the server may indicate that the total of the item lines does not match the document total or the total by payment methods. The code itself does not identify a specific Torgsoft setting.

A «Prepayment» line for a few kopecks does not always mean that the cashier accepted additional money. It is often a calculated remainder that the software obtained when comparing:

1. the composition and amounts of goods in the current invoice;

2. the already registered prepayment;

3. the current payment;

4. rounding;

5. the distribution of the payment between Sole Proprietorships or legal entities.

Different Torgsoft releases included fixes for individual code 9 scenarios: fractional discounts, partial payments, cash rounding, combinations of fiscal and non-fiscal goods, bonuses, foreign-currency invoices, and the distribution of sales between businesses. Therefore, proper diagnostics begin with checking the current software version, but an update itself does not change an already registered receipt or restore a broken link between old documents.

What equation must be satisfied in a fiscal receipt

In simplified terms, the pECR checks whether three parts of the document are consistent with one another: the total of fiscal item lines after discounts and rounding = the amount of the current settlement = the total by payment methods.

For a prepayment, the check is more complex because the current receipt must also correctly account for previously fiscalized amounts and the outstanding balance. The software may simultaneously use the following values:

• «Amount» — the calculated document amount before cash rounding;

• «Amount Due» — the amount the customer must actually pay after the applicable rounding rule;

• previous payments;

• current payment;

• debt;

• amounts of individual receipts if the sale is divided between businesses.

If one part of the algorithm used UAH 999.97 and another used the rounded UAH 1,000.00, the UAH 0.03 difference becomes significant for validation. The State Tax Service does not allow a «few-kopeck tolerance»: the control totals must match exactly.

Where one, several, or dozens of kopecks come from

 1. Proportional distribution of a partial payment among goods

When a customer pays only part of the amount, Torgsoft distributes it among the goods proportionally to their value. Before rounding, the result often contains more than two decimal places.

For example, an order contains goods worth UAH 199.99 and UAH 100.01, totaling UAH 300.00. The prepayment is UAH 100.00. The mathematical shares are approximately UAH 66.6633 and UAH 33.3367. On the receipt, they must become UAH 66.66 and UAH 33.34 so that the total remains UAH 100.00.

Add a fractional quantity, a discount with a non-integer percentage, or division into several receipts, and the last kopeck must deliberately be assigned to one of the lines. If different calculation stages round the shares differently, a UAH 0.01 remainder appears.

2. Difference between the document amount and the cash «Amount Due»

Torgsoft has separate mechanisms for:

• rounding the total receipt amount;

• rounding cash payments only for Ukraine;

• applying rounding in invoice-based sales mode.

Global rounding of the receipt total affects the entire document and takes priority over individual price rounding by product type. Special cash rounding should apply to the cash portion, not to card payments or other cashless payments.

Since October 1, 2025, the National Bank has been gradually withdrawing 10-kopeck coins from cash circulation. They remain legal tender, but if such coins are unavailable at the cash register, the total cash payment is rounded to 50 kopecks: 1–24 kopecks — to 00, 25–49 kopecks — to 50, 51–74 kopecks — to 50, 75–99 kopecks — to the next hryvnia. Cashless payments are not rounded. The rules are explained by the National Bank of Ukraine.

Practical scenario: the invoice amount is UAH 249.97. When a cash prepayment is made, the cash register accepts UAH 250.00 after rounding. If the final settlement subsequently subtracts exactly UAH 250.00 from the original document amount, while the goods or debt block is calculated from UAH 249.97, a UAH 0.03 discrepancy occurs. A historical fix for this type of issue in Torgsoft is described in change No. 201060: the payment, prepayment, and debt block must take into account the «Amount» value rather than only the «Amount Due» value. Details are provided in the version 2022.4.7 description.

3. Changing the invoice after fiscalization of the prepayment

This is one of the most important scenarios. The initial prepayment receipt has already recorded specific goods, quantities, prices, discounts, and the amount with the State Tax Service. If, after that, the invoice is changed by:

• changing the price;

• adding or removing a product;

• changing the quantity;

• applying a different discount;

• changing the fiscal status of a product;

• redistributing goods between businesses,

the final settlement is based on the new state of the document, while the previous fiscal transaction remains in its original state.

For example, after the prepayment, the cashier increased the price of one item by UAH 1. During the next proportional distribution, this hryvnia may change the shares of several products, resulting not in exactly UAH 1, but in a technical «Prepayment» remainder of UAH 0.01 or UAH 0.59. These causes are described in the Torgsoft guide on prepayment receipts.

The correct procedure for changing an order after a fiscal prepayment is:

1. make sure that the original receipt is actually registered with the State Tax Service;

2. process a fiscal prepayment refund using the standard operation;

3. change the composition, quantity, price, or discount in the document;

4. accept the payment again;

5. generate a new prepayment receipt or final settlement receipt.

Do not compensate for the remainder with an arbitrary product or service worth UAH 0.01: this hides the cause but changes the composition of the payment transaction.

4. Splitting one sale between several Sole Proprietorships

The «Link product type to a business and split sales by it» setting allows goods to be sold in a single basket while creating separate sales and fiscal receipts for the businesses to which the corresponding product types are linked. The customer's total payment is distributed among the sales proportionally to their totals.

For example, a customer pays UAH 1,000.00 by card, while the goods belong to two Sole Proprietorships in a ratio that produces shares of UAH 333.335 and UAH 666.665. A payment document cannot record half a kopeck. One receipt must receive UAH 333.33 and the other UAH 666.67; otherwise, their total will not equal UAH 1,000.00.

In the current Torgsoft algorithm, the rounding remainder is assigned to one of the receipts so that the total amount matches. For a sale split among more than two businesses, the previous portions are rounded down to the nearest kopeck, and the remainder is assigned to the last one. Cash rounding to 10 or 50 kopecks is also taken into account separately. This change for distribution between businesses is described in version 2026.0.3, task No. 205082.

However, a correct total amount does not yet mean that the configuration is complete. For each business, check:

• whether the product type is linked to the correct Sole Proprietorship or legal entity;

• the corresponding pECR and its valid fiscal number;

• the payment method;

• the bank account and acquiring, if a card is used;

• the total of the item lines and the payment amount in the individual receipt of that business.

Each receipt is validated independently. The server does not compensate for a UAH 0.01 shortage in one Sole Proprietorship's receipt with a UAH 0.01 surplus in another Sole Proprietorship's receipt.

5. Fiscal and non-fiscal goods in one document

If an invoice contains both goods that must be included in the fiscal receipt and items that are not fiscalized, the payment document may cover the entire invoice while the pECR receipt covers only the fiscal portion. With a partial payment, the software must determine which part of the payment belongs to each group.

Fractional shares and rounding in such combinations previously caused individual cases of code 9. Fixes are described, in particular, in version 2022.0.57 and other updates. If the scenario is reproduced in the current version, check the fiscal status of each item and do not equate the amount of the entire invoice with the amount of the fiscal receipt without calculation.

6. Uneven distribution of bonus payments

When one item is paid for entirely with bonuses and the rest using another payment method, proportional distribution and rounding may temporarily produce a bonus share for a product that is one kopeck higher than its value. This scenario, including in refund receipts, was fixed in update 2022.0.59.

During verification, compare not only the total amount of bonuses but also their distribution across each item line.

7. Foreign-currency document and fiscal settlement in hryvnias

Fiscal transactions in Ukraine are carried out in hryvnias. If an invoice or settlement is maintained in a foreign currency, different exchange rates or conversion times may result in a hryvnia equivalent with a discrepancy of a few kopecks. Torgsoft's update history separately describes code 9 for partial cashless payment of a foreign-currency invoice when the payment amount did not equal the invoice amount in the national currency.

For the pECR, check the hryvnia values transmitted to the receipt. A foreign-currency amount should not be fiscalized as a hryvnia amount without correct conversion.

8. Deleting or reversing one of the linked documents

An accounting record in Torgsoft and a receipt registered with the State Tax Service have different statuses. If a previous payment is deleted, a local document is reversed, or the database is restored from an old backup, the fiscal server will not automatically cancel an already accepted receipt. The next settlement may see a different payment history from that held by the State Tax Service.

Therefore, do not delete a payment, receipt, offline package, or link between documents to «zero out the kopecks». First determine the fiscal status of each receipt.

Step-by-step check: how to find the specific cause

Save the full response text and take a screenshot. Open the pECR analytics and determine whether the receipt:

• was rejected by the server;

• was registered, but the response did not reach the software;

• remained in the queue or offline package;

• was reversed or refunded.

Generating it again without this check may create a duplicate payment transaction.

DocumentValidationError is a category, not a diagnosis. Note the following information from the message:

• the total of the item lines;

• the document amount or current payment amount;

• the total by payment methods;

• the size and sign of the discrepancy;

• the name of the field or block that the server considers inconsistent.

If the text contains two amounts, subtract the smaller from the larger. The resulting UAH 0.01, 0.03, 0.50, or 0.59 will help you match the situation to a specific type of rounding.

Record exactly what was being generated:

• the first prepayment;

• a subsequent partial payment;

• the final settlement;

• a prepayment refund;

• a reversal;

• a regular sale;

• a sale split between businesses.

If the «Prepayment» line appeared only in the final receipt, first check whether the original prepayment matches the current state of the invoice.

For one order, open and compare:

1. the invoice or order;

2. the sales invoice;

3. the financial document for the first payment;

4. the first fiscal prepayment receipt;

5. subsequent payments and receipts;

6. refunds or reversals, if any;

7. the current receipt that failed validation.

You need to determine not only the current amounts, but also the sequence of events.

Compare the original receipt with the current invoice using the following fields:

• the product and its fiscal name;

• quantity;

• price;

• discount;

• tax rate and tax group;

• fiscal status;

• product type and linked business;

• currency and hryvnia equivalent.

Even if the total amount changed by a whole hryvnia, proportional distribution between items may result in a remainder of a few kopecks.

Open Settings → Parameters → Receipt and check:

• «Round receipt amount»;

• «Round cash payments (Ukraine only)»;

• the rounding increment — 10 or 50 kopecks;

• «Use rounding in invoice-based sales».

Determine which settings were in effect on the date of the first prepayment, not only which ones are set now. Do not change them in the production database during an open shift without understanding their impact on other cash registers.

Check the payment method separately. If the entire payment was made by card, special cash rounding should not apply. For mixed payments, only the cash portion is rounded.

The «Print invoice receipt on pECR» setting has the following modes:

• «For the payment amount»;

• «For the payment and debt amount»;

• «Ask the user».

These modes affect the amount the software must fiscalize during a prepayment or partial settlement. Their logic is described in update 2022.0.48. If the cashier expected a receipt only for the actual payment but the selected mode also included the debt, the search for the discrepancy should begin with the mismatch in the receipt type rather than manually adjusting the amount.

Create a simple table:

Check two equations:

• in each row, the total of the goods equals the payment amount of the corresponding receipt;

• the total of all individual receipts equals the customer's payment.

If the first equation is not satisfied, the cause lies in the individual receipt or the business link. If the first equation is satisfied but the second is not, check the remainder distribution algorithm and the Torgsoft version.

Do not rely on a single «minimum version». Fixes accumulated across several releases:

• 2022.0.49 — partial payments, fractional discounts, cash rounding, overpayments, and prepayment refunds;

• 2022.0.57 — individual discrepancies involving fiscal and non-fiscal items;

• 2022.0.59 — foreign-currency invoices and uneven bonus payments;

• 2026.0.3 — distribution of the rounded amount between businesses.

Descriptions of individual scenarios are available in update 2022.0.49, 2022.0.59 and 2026.0.3.

Before updating, create a backup copy of the current database. If the discrepancy concerns an old document, it is safer to reproduce the issue using a copy of the database together with a technical specialist.

What to do after identifying the cause

What not to do

• Do not add an arbitrary «Rounding» service or a UAH 0.01 product merely to balance the receipt.

• Do not change the product price by a few kopecks after fiscalizing the prepayment.

• Do not delete a local receipt, payment, or offline package without checking the document status with the State Tax Service.

• Do not replace the final settlement with a regular sale: it will not have the correct link to the prepayment.

• Do not switch the pECR, Sole Proprietorship, or payment method after accepting the payment without checking the entire chain.

• Do not disable rounding at all cash registers at once unless you have determined which specific rule caused the discrepancy.

• Do not manually edit fiscal tables in the database.

How to quickly identify the source by its symptoms

Frequently asked questions

Not necessarily. It may be a technical remainder resulting from proportional distribution or from comparing the previous fiscal amount with the current document. The customer's debt is checked against the invoice and financial documents, while the origin of the line is determined from the chain of fiscal receipts.

The fiscal server checks the exact arithmetic consistency of the receipt details. A one-kopeck difference means that the item totals, the overall total, or the payment methods do not match.

No. DocumentValidationError covers various structural and control-relation errors. You need to read the entire response text. The general logic of the code is explained in the Torgsoft guide.

At this stage, the software reconciles the current invoice composition, all previous payments, and the remaining balance. If the document was changed after the first receipt or different rounding rules were applied at different stages, the discrepancy appears at the end.

An update fixes the algorithm for subsequent calculations, but it does not rewrite a receipt already registered with the State Tax Service. For an old document, you still need to determine its status and correctly process a refund or complete the settlement.

No. It is a calculated element of the receipt. Manual deletion does not eliminate the discrepancy between item amounts and payment and may create another inconsistency.

No. Cash rounding rules apply to cash payments. For mixed payments, the cash and cashless portions must be checked separately.

For the customer, the transaction may begin with one basket and one total amount. Torgsoft divides it into separate sales and receipts. Each Sole Proprietorship must have its own correct receipt, pECR, and corresponding share of the payment; the total of the individual parts must equal the customer's payment.

Only after confirming that the previous attempt was not registered. First check the pECR analytics and the document status on the fiscal server.

What to prepare for technical support

To help a specialist identify the source of the discrepancy, provide:

• a full screenshot showing the code and response text;

• the Torgsoft version number;

• the number and date of the invoice, order, sales invoice, and sale;

• the number of the first fiscal prepayment receipt;

• the amount of the first, subsequent, and current payments;

• the «Amount», «Amount Due», previous payment, and debt values;

• payment methods and their amounts;

• a list of Sole Proprietorships, pECRs, and parts of the sale if the sale is split;

• information on whether the product, quantity, price, discount, or product type was changed after the prepayment;

• screenshots of the rounding settings;

• the status of all related receipts in the pECR analytics.

Do not send your personal QES key file or its password.

You can create a request directly in the software: Help → Technical Support Request.

The following official channels are also available:

•  phone: +38 (067) 558-37-84, Monday–Saturday, 09:00–18:00;

•  Telegram: @torgsoft_help;

•  email: info@torgsoft.ua.

Current contact details and the procedure for submitting a request are published on the Torgsoft technical support page and in the instructions for creating a request.

Checklist before repeated fiscalization

1. Check that the previous receipt has not been registered with the State Tax Service.

2. Save the full DocumentValidationError text.

3. Determine the transaction type and the exact amount of the discrepancy.

4. Compare the original prepayment with the current invoice.

5. Check the «Amount», «Amount Due», payment method, and rounding settings.

6. For multiple Sole Proprietorships, check each receipt and the overall total.

7. Compare the Torgsoft version with the descriptions of fixed scenarios.

8. Create a database backup before making changes or updating.

9. Fix the actual source of the discrepancy: the document, setting, link, or refund sequence.

10. Generate the receipt again only after checking the statuses and amounts.

This procedure makes it possible to distinguish arithmetic rounding from an invoice change, incorrect distribution between businesses, or a broken link to the previous fiscal document. This is important because the same «Prepayment» line may result from different transactions, while code 9 only indicates that the receipt totals failed validation.