Partial payment in "Trade with invoicing": how to select the PECR receipt mode and correct amount discrepancies

In the «Trade with invoicing» mode, an entrepreneur can create an order, accept a prepayment or several payments, ship the goods and keep track of the customer’s outstanding balance. The most common questions concern selecting the fiscalization mode for partial payment, generating receipts for subsequent payments, using the «Ask user» mode, STS errors and correcting already registered fiscal documents. 

What partial payment means in Torgsoft

Trade with invoicing is used when placing an order, receiving payment and transferring goods take place at different times. The entrepreneur first creates an invoice, then records the payment and, upon the actual shipment, creates a delivery note.

When working with PECR, it is important to distinguish several operations:

• prepayment — the customer pays part of the amount before the final settlement;

• subsequent payment — the customer pays the next part;

• final settlement — the payment closes the remaining balance;

• debt — the part of the document value that the customer still has to pay;

• fiscalisation — transmission of the generated settlement document to the STS fiscal server.

In Torgsoft, these amounts are interconnected. The software takes into account payments already made, the current payment and the remaining balance under the document.

What rule applies to partial payments

Torgsoft’s technical setting determines how the software generates the receipt. The obligation to use PECR is determined by the nature of the settlement transaction itself. Law No. 265 classifies, among other things, acceptance of cash and payments using a payment card as settlement transactions. 

The STS specifies the procedure for installment payments: if the customer pays in several instalments in cash or by payment card, a separate fiscal receipt is issued for each part of the payment. PECR provides the transaction types «Prepayment», «Subsequent payment» and «Final settlement». For subsequent and final payments, previous payments and the fiscal number of the first prepayment receipt are specified. 

This STS clarification was republished on 5 August 2026.

A separate case is when the customer transfers funds directly to the seller’s current account using IBAN details. Under the conditions described by the STS, such a transaction may be carried out without ECR/PECR. If, after an IBAN prepayment, a settlement transaction through PECR or transfer of goods takes place, the amount previously received must be taken into account in the corresponding fiscal receipt. 

Therefore, before selecting a mode in Torgsoft, three things must be established: when the customer receives the goods, how much they are paying now and how the remaining balance will be paid.

Where invoice receipt printing is configured

In Torgsoft, the setting is located at: Settings → Parameters → Receipt → Print invoice receipt on PECR.

Three scenarios are available for partial payments:

«For the payment amount» mode: when the customer pays in instalments

This mode corresponds to a sequence in which several payments will be made under one invoice.

For example, the order amount is UAH 12,000:

1. the customer pays UAH 3,000;

2. later pays another UAH 4,000;

3. the final payment is UAH 5,000.

For the first partial payment, Torgsoft generates a prepayment receipt. If the second payment does not yet close the document, a subsequent-payment receipt is generated. When the final payment fully closes the balance, a final-settlement receipt is generated.

In subsequent receipts, Torgsoft uses the fiscal number of the first prepayment receipt. This allows the STS to link settlements relating to one business transaction. 

What happens to goods in the receipt

Partial payment does not mean that one physical unit of goods must artificially be converted, for example, into 0.25 units.

For prepayment, subsequent-payment and final-settlement receipts, the full quantity and full value of the goods in the document are specified, while the amount of the specific receipt corresponds to the amount of the current payment. The receipt also shows previous payments and the remaining debt. This is an important clarification for partial payments: the payment amount and the quantity of physically sold goods should not be mechanically equated.

For the first advance payment, the STS requires identification of the goods for which the funds were received.

What happens during final settlement

The STS separately describes the situation where goods are transferred to the customer after previous advance payments.

The final receipt must contain:

• the full list of goods;

• the full price;

• quantity;

• previously received advance payments (prepayments);

• the amount remaining to be paid after taking advance payments into account.

This also applies when the customer has fully paid for the goods in advance by the time they are handed over: the final document must still properly reflect the sale itself and the previous payments. 

«For the payment and debt amount» mode: why it requires attention

In this mode, Torgsoft allows the current payment together with the outstanding debt to be recorded in the receipt. For the debt portion, the operator specifies the corresponding payment form and payment method.

For example:

• invoice value — UAH 12,000;

• the customer now pays UAH 3,000;

• debt — UAH 9,000.

If «For the payment and debt amount» is used, Torgsoft treats the generated receipt as final for this invoice. After such a receipt, another receipt can no longer be generated when the customer later pays the remaining amount under this invoice.

This is why a common question arises: «Why did the customer pay the remaining debt, but the software no longer offers to print a receipt?»

The reason is the selected scenario: the debt was already included in the previous fiscal document as part of the final processing of the transaction.

When this mode should not be set as universal

As of August 2026, the STS position is stated clearly: if the customer pays for goods in several instalments in cash or by card, each part of the settlement must be accompanied by a separate fiscal receipt.

Therefore, for the scheme: UAH 3,000 by card now → UAH 4,000 by card in a week → UAH 5,000 by card at final settlement a mode after which Torgsoft no longer generates receipts for subsequent payments requires a considered decision. For ordinary sequential installment payments, it is logical to use the mechanism prepayment → subsequent payment → final settlement.

If the future part of the debt will be repaid by direct transfer to IBAN, the procedure is different: under the conditions provided by the STS, such a payment may be made without PECR. At the same time, it must be correctly reflected in the fiscal document when the next settlement transaction occurs or the goods are transferred. 

Therefore, «For the payment and debt amount» should not be selected only to close the receipt once. First, determine how the future debt will be repaid and when the goods will be transferred.

«Ask user» mode: when the store has different scenarios

This mode leaves the choice to the operator immediately before the fiscal document is generated.

It is appropriate when one company works with different types of orders. For example, some customers make several card payments, some make a prepayment and collect the goods later, while certain B2B customers pay the remaining balance by direct bank transfer.

Before making a choice, the cashier needs to know:

1. Whether the goods are being handed over to the customer now.

2. Whether there have already been fiscal receipts under this document.

3. How much the customer is actually paying now.

4. Whether any debt will remain.

5. How the customer will repay this debt: in cash, by card or by IBAN transfer.

6. Whether a fiscal receipt will need to be generated for the next payment.

The «Ask user» mode itself does not automatically determine the required fiscal scenario. The cashier selects it according to the actual transaction. Therefore, with this setting, it is advisable to establish a short internal rule for employees.

Why the STS returns «Totals by payment forms do not equal the total amount»

For partial payment, PECR must transmit a mathematically consistent fiscal document to the STS server. In simplified form, the following relationship must hold within one receipt: value of item lines taking discounts and adjustments into account → receipt total → amounts by payment forms.

If these parts of the document produce different results, the STS server may return: Error code: 9 DocumentValidationError and a specific explanation, for example: Totals by payment forms. The amount by lines … does not equal the total amount in the document …

Code 9 denotes a class of rejection. The cause is determined by the text following DocumentValidationError. The Torgsoft knowledge base separately notes that amount discrepancies and partial payments are among the common causes of this message.

Where a one-kopeck difference can come from

For partial payments, several possible sources of discrepancy should be checked.

Rounding. The first payment may have been made in cash and rounded. The next payment is calculated based on the amount actually registered in the previous receipt. If the original pre-rounding value is used in the calculation, the totals may differ.

Percentage discount and fractional quantity. Weight-based or measured goods, a percentage discount and partial payment create several successive rounding operations. Each item line has precision to one kopeck, so the sum of rounded lines may sometimes differ from the mathematical total before rounding.

Fiscal and non-fiscal items. If an invoice contains both types of goods, Torgsoft distributes the prepayment between them proportionally. Only the fiscal part is transmitted to the PECR. A discrepancy may arise at the rounding boundary.

Several Sole Proprietorships or companies. When one sale is split between different companies and PECRs, the total payment must also be distributed. Mixed payments, discounts and rounding should be checked particularly carefully.

Foreign-currency invoice. If the document is accounted for with reference to a foreign currency, the software must correctly determine the amount in hryvnias for the fiscal document. Exchange-rate changes, partial payment and rounding may affect the balance.

Incorrectly determined payment method. A bank card via acquiring and a direct transfer using IBAN details are different in nature. If the actual payment is recorded differently in Torgsoft, the calculation of the fiscal part may not correspond to the real transaction.

Changing the document after fiscalization. If a receipt has already been registered on the STS server, subsequent editing of the local invoice or payment does not change that receipt. As a result, Torgsoft and the STS begin to operate with different amounts.

What to do if DocumentValidationError reports an amount discrepancy

1. Add the full error text after code 9

If the message concerns line amounts or payment forms, continue checking according to this instruction.

If the text after the code mentions QES, the retail outlet address, XML, timestamp or another parameter, the cause is different.

2. Check whether the receipt is registered with the STS

Before repeating fiscalization, determine the document status.

Check:

• whether a fiscal number has been assigned to the receipt;

• whether it appears in PECR Analytics;

• whether Torgsoft received a response from the STS server.

This step is needed to avoid registering again a transaction that has already been accepted by the STS.

3. Reconcile four amounts

For the invoice, check: document amount → previous payments → current payment → remaining debt.

For example:

• document — UAH 12,000;

• previously paid — UAH 3,000;

• paid now — UAH 4,000;

• remaining balance — UAH 5,000.

If one of these amounts in Torgsoft differs from the actual payments, first determine the cause.

4. Check the mode used to generate the receipt

With «For the payment amount», the current receipt must correspond to the current settlement stage.

With «For the payment and debt amount», check whether the document has already been fiscally completed with the debt portion.

With «Ask user», determine what exactly the cashier selected when generating this receipt.

5. Check discounts, rounding and fractional quantity

This is particularly important if the difference is UAH 0.01 or a few kopecks.

Do not manually adjust a random item by one kopeck merely to pass STS validation. First determine the source of the discrepancy.

6. Check payment forms and payment methods

In a settlement document, the payment form and the amount under that form are mandatory details. Requirements for the form and content of the fiscal receipt are established by Regulation No. 13. 

Compare the actual payment method with what is transmitted to the PECR:

• cash;

• card via acquiring;

• other cashless payment;

• credit or debt, if used in the specific scenario;

• direct transfer using IBAN details.

7. If there are several companies, check the distribution

Make sure that:

• the goods belong to the required company;

• the required PECR is used for it;

• the current payment is correctly distributed between companies;

• after distribution, the totals of all receipts correspond to the total payment.

8. Check the Torgsoft version

In different Torgsoft versions, developers have adjusted algorithms for partial payments, rounding and fiscal document generation. If the situation is reproduced in an older version, first check it on the current update.

Can an invoice be changed after printing the fiscal receipt

A registered receipt already exists on the STS side. Changing data in Torgsoft does not itself cancel it.

Therefore, after fiscalization, you should not:

• delete a posted payment in order to enter it again;

• change the amount or contents of the document without checking the consequences;

• resend the same transaction while the status of the first receipt is unknown;

• create a manual one-kopeck adjustment to reconcile totals.

If a registered transaction really needs to be cancelled, the prescribed return or adjustment procedure with the corresponding fiscal document is used.

If the STS rejected the receipt and there is no fiscal number, the situation is different: the cause in the source data must be corrected and a valid document generated.

What to choose for typical scenarios

What to provide to technical support if the amounts do not match

To allow a specialist to reproduce the situation, prepare:

1. The full STS response text after DocumentValidationError.

2. The date and approximate time the receipt was generated.

3. The amount of the invoice or delivery note.

4. The amount of all previous payments.

5. The amount of the current payment and remaining debt.

6. The selected mode: «For the payment amount», «For the payment and debt amount» or «Ask user».

7. The method of each payment: cash, card, IBAN.

8. Information about discounts, rounding or fractional quantity of goods.

9. Information about several Sole Proprietorships if the sale is split between companies.

10. The Torgsoft version.

11. The fiscal number of the previous receipt, if it already exists.

The QES password and other confidential data are not required for such diagnostics.

A short rule for working with partial payment

If the customer pays for goods in several cash or card payments, follow the principle that each part of the settlement has its own fiscal receipt. Torgsoft supports the sequence «Prepayment», «Subsequent payment» and «Final settlement» for this purpose. 

The «For the payment amount» mode corresponds to such staged fiscalization. «For the payment and debt amount» completes the fiscal scenario of the invoice in Torgsoft logic, so before using it, the method of future debt repayment must be taken into account. «Ask user» is suitable for businesses with several settlement schemes, provided the employee understands the difference between them.

The main rule when amounts differ is to first check the status of the receipt already generated, then reconcile the document, previous payments, current payment, debt and payment forms. Repeated fiscalization without this verification may create another problem.