According to legal requirements, in online trade, custom-order sales, or installment sales, entrepreneurs must fiscalize not only the transfer of goods but also the receipt of an advance payment.
The prepayment fiscalization mode in Torgsoft creates the correct chain of receipts: from the «Prepayment» receipt (showing the paid part of the product) to the «Final settlement» receipt (with a reference to the fiscal number of the first payment and the remaining debt displayed).
However, in practice, this process is one of the most difficult for users. Entrepreneurs most often contact technical support when the PECR rejects a prepayment or postpayment receipt with the DocumentValidationError (code 9) due to discrepancies in amounts down to a kopeck, the impossibility of processing mixed payment, the appearance of a phantom «Previous payment» in regular receipts, or difficulties when trying to return an advance payment.
This article explains in detail the technical causes of errors during prepayment fiscalization and how to avoid them.
How the prepayment fiscalization algorithm works in Torgsoft
Since there is no single approved State Tax Service standard for generating partial payment receipts, Torgsoft has implemented a mechanism based on official tax authority explanations.
-
Prepayment receipt. When an advance payment is made for an invoice or order, the product quantity in the receipt is calculated proportionally — as the ratio of the prepayment amount to the total receipt amount. The phrase «Prepayment for» is automatically added before the product name.
-
Next payment receipt / Final settlement. For subsequent payments, a receipt is generated that contains the fiscal number of the first prepayment receipt. It shows the full value and quantity of the goods, but only the amount of the current payment or the remaining debt is displayed for payment.
Typical errors and solutions (Troubleshooting)
1. Error DocumentValidationError (code 9): the line-item amount does not equal the total amount in the document
This is the most common error that blocks the printing of a prepayment or final settlement receipt. It means that the value of the goods in the receipt XML file does not match the total payment amount sent to the State Tax Service. The main causes are:
- Fractional product quantity and non-integer discounts. If an invoice contains products with fractional quantities, for example weighted goods, and complex discounts or rounding are applied to them, an error could occur when calculating the prepayment proportion, causing the line-item amount to differ from the document amount.
-
Solution: this issue was fixed globally in Torgsoft updates, starting from versions 2022.0.57 and 2022.4.10, by increasing the accuracy of price calculations. The program must be updated.
-
Fiscal and non-fiscal goods in one invoice. If you ship a fiscal product and a non-fiscal service, for example delivery, Torgsoft tries to proportionally divide the prepayment amount between the fiscal and non-fiscal parts. During rounding, especially with partial or mixed cash + card payments, this often led to an error.
-
Solution: update the program to the latest version. As a preventive measure, it is recommended to issue separate invoices for fiscal and non-fiscal items, or make all goods/services in the database fiscal.
-
Prepayment for an invoice in foreign currency. The software ECR works exclusively with the national currency, the hryvnia. If an invoice is created in a foreign currency, for example USD or KZT, and the prepayment is made in hryvnias, a kopeck-level discrepancy occurs due to exchange rate conversion, and the partial payment amount becomes higher or lower than the document amount.
-
Solution: developers disabled the possibility of directly generating fiscal receipts from payments made in a currency other than the national currency. To avoid errors, settlements that require fiscalization should be conducted only in hryvnias.
-
Cash rounding issue. If the debt amount for an invoice is not a multiple of 10 kopecks and the payment is made in cash, a discrepancy may occur when generating a final settlement or overpayment receipt.
-
Solution: Torgsoft cancelled automatic rounding to 10 kopecks for PECR receipts if there is no cash in the document payment forms.
2. A «Previous payment» line suddenly appears in the receipt for a few kopecks
Entrepreneurs sometimes notice that in regular fiscal receipts or when generating an outgoing invoice, an unclear payment form «Previous payment» appears, for example for 1 or 59 kopecks, increasing the total receipt amount.
-
Cause 1 (Price change). The user created an invoice, accepted a prepayment for it, then changed the selling price of the product in the invoice, for example increased it by UAH 1, and created an outgoing invoice by paying the difference.
-
Cause 2 (Payment with bonuses). When paying for a sale with bonuses, if the bonus amount fully covered the value of one of the items, the rounding mechanism could make the program interpret that the product was paid with bonuses in an amount greater than its value. This difference appeared in the PECR as «Previous payment».
- Solution: do not change prices, quantities, or discounts in an invoice after a fiscal prepayment receipt has already been printed for it. The bonus-related error has been fixed in newer versions.
3. Error «The fiscal number of the document for which the return is being made is not defined»
This occurs when trying to return a customer’s prepayment in the «Trading with invoice issuance» mode.
-
Cause. An attempt is made to print a fiscal receipt for the return of an advance payment, although the receipt for receiving this advance payment was not printed or was processed as non-fiscal.
- Solution: the PECR cannot return a fiscal prepayment that does not exist in the tax authority registers. In this case, the return should be made without printing a fiscal receipt.
4. Negative amounts in the fiscal prepayment receipt
In older versions of the program, for example 2022.0.3, when generating a receipt for an outgoing invoice that had a prepayment, if the receipt contained 2 units of the same product, the receipt generated a negative payment amount and negative quantity.
- Solution: update Torgsoft.
Main rules for error-free work with advance payments
-
Sequence of actions. The correct algorithm for working with online orders: Create an invoice -> Enter a prepayment with receipt printing -> Create an outgoing invoice -> Click «Payment for outgoing invoice against prepayment» -> Print the receipt for the remaining debt.
-
No retroactive changes. If a fiscal prepayment has already been entered for a document, order, or invoice, it is forbidden to add/delete goods or change their quantity or price. This will inevitably cause the amounts not to match during final settlement, resulting in the DocumentValidationError. If the order has changed, you must first make a fiscal return of the prepayment for the full amount, make changes to the document, and only then fiscalize the advance payment again.
-
Do not delete partial payments. Deleting payments for which a fiscal receipt has already been printed is strongly not recommended, because the receipts remain with the State Tax Service. Always use the prepayment return mechanism.
Legal provisions
As of May 2026, the basic rule is as follows: if an entrepreneur accepts payment for goods through an ECR/PECR, they must process the transaction for the full amount of the operation and provide the buyer with a paper or electronic settlement document; this also applies to online orders. In simple terms: not only “handed over the goods — issued a receipt”, but also “received part of the money — correctly showed this part in the receipt chain”. The State Tax Service explains: in case of an advance payment, the first receipt must show “advance payment for…” with the name or article number of the product and the amount actually received; the final receipt must contain the full item list, full price, quantity, previously received advance payment, and the amount payable after it is deducted. If the advance payment was received specifically as a bank transfer from account to account via IBAN without releasing the goods, the State Tax Service indicates that such an advance itself may not require an ECR/PECR, but it must later be reflected in the first fiscal receipt when the next payment through ECR/PECR is made or the goods are released. Sources: Law of Ukraine No. 265/95-VR, Art. 3, Art. 9; State Tax Service explanations on advance payments. (Law of Ukraine)
In Torgsoft, it is better to process this through the special prepayment fiscalization mode: create an invoice or order, accept an advance payment and print the “Prepayment” receipt, and upon shipment generate a final settlement receipt linked to the first fiscal receipt and showing the remaining debt. The program helps build the correct document chain so that the State Tax Service does not receive “detached” payments, and the buyer does not see unclear amounts. After the first fiscal receipt, you should not change the price, quantity, discount, or order composition: for the PECR, this looks as if the first and final receipts describe different operations, which causes discrepancies down to a kopeck. If the order has changed, the safer approach is to return the fiscalized advance payment, correct the order, and process the payment again. Under Ministry of Finance Order No. 13, a fiscal receipt must contain, in particular, the name of the product/service, quantity and value, payment form, amount, and fiscal number, so “minor” kopeck discrepancies are not legally minor for the PECR. (Law of Ukraine)
A practical rule for retailers: work in hryvnias, update Torgsoft to the latest version, do not unnecessarily mix fiscal and non-fiscal items in one complex invoice, do not delete fiscalized partial payments, and when returning an advance payment, use the return mechanism specifically. If the advance receipt was not fiscalized, the PECR will not be able to correctly make a fiscal return of “something that does not exist” in the fiscal chain. A short example from a practical State Tax Service publication: the buyer made an advance payment and then refused the goods; the State Tax Service explains that when returning goods purchased with payment in parts, the entire chain of receipts within that sale must be cancelled. For business, this means: do not correct an advance payment “retroactively”, but create a transparent sequence of receipts. Otherwise, the risk is not only the DocumentValidationError, but also a fine for failing to process a settlement or processing it for an incomplete amount: Art. 17 of Law No. 265/95-VR provides financial sanctions of 100% of the violation amount for the first violation and 150% for subsequent violations. (zir.tax.gov.ua)
Go back to the previous step