Advance receipts: issuing them, closing them, and where it goes wrong

Advances are the biggest source of mistakes in fiscalization, and not because they are complicated but because people think they do not have any. A payment received up front from a natural person for work that will be done later is, as we understand it, an advance received for a future retail sale, and it is fiscalized when the money arrives: cash and card at once, a bank transfer by the next working day at the latest.

When an advance receipt is issued

At the moment the money is received, not when the goods are delivered or the service performed. If a customer pays a deposit on Monday for furniture arriving in three weeks, the advance fiscal receipt is issued on Monday.

The obligation applies whatever the payment method. For a bank transfer the rule is, as we understand it, a special one: the advance receipt is issued no later than the next working day after the payment arrives, and if it is issued on a later day than the payment, it states the payment date in the ESIR time field.

What an advance receipt looks like

An advance receipt is a receipt of type Аванс (Advance), transaction type Продаја (Sale). What differs from an ordinary receipt is the line items.

Under the Tax Administration's technical guide (section 9.1.1), an advance does not list the articles but the amount paid per tax rate; the articles the advance is for may, at the buyer's request, be written in the advertising field below the receipt. The item name is prescribed and starts with a code:

The code follows the tax treatment: 10 for the standard 20% rate, 11 for the special 10% rate, 12 for a VAT exempt sale and 13 for a taxpayer outside the VAT system. Neither the rate nor the label letter is enough on its own: 12 and 13 share the same 0% rate, and the tax labels are set by the Fiscalization Management System (Rulebook, article 5), so, as the technical guide notes, in the development environment they can differ from the examples. A register that infers the code from the letter writes 10: onto every line in such a case, which is wrong for everything except the standard rate.

The quantity is always 1 and the price is the amount received.

Closing an advance: two steps, in that order

When the work is done, the advance is closed. Many people expect the final receipt to simply be reduced by the advance received. It does not work like that.

1. A receipt of type Advance, transaction type Refund, is issued. It cancels the advances recorded earlier. As its referent document it carries the number and date of the last advance receipt. Under the technical guide this receipt is not handed to the buyer.
2. A final receipt of type Normal (Промет), transaction type Sale, is issued for the full value of what was delivered, with the real line items. As its referent document it carries the number of the advance refund receipt, and the number and date of the last advance receipt go into the advertising field below the receipt.

The result is that the advance went into turnover once, came out once, and the final receipt carries the full value. The totals are right and the trail is complete.

Partial advances and several payments

If the customer pays in several instalments before delivery, every payment is its own advance receipt, and each further advance receipt carries the number of the previous one as its referent document. When delivery comes, one advance refund is issued for the sum of all the advances, referring to the last advance receipt, and only then one final receipt. Selling on instalments after delivery is a different case: then, as we understand it, one normal receipt for the full amount is issued at delivery.

If the advance covered the whole amount, the final receipt is still issued, for the full value. It shows how much was paid by advance, and the amount to pay is zero: the advance received is not entered again as a payment.

When the deal falls through

If delivery never happens and the money goes back to the customer, an advance refund is issued, but with no final receipt after it. The advance has left turnover and that is the end of the story.

If the advance is kept as a contractual fee, that is a different legal situation and it is worth asking your accountant before typing anything in.

Four mistakes that keep repeating

• The advance is not recorded and delivery is waited for. That is a failure to record a sale at the moment it arose.
• The final receipt is issued reduced by the advance. Turnover then comes out lower than it is, and the advance stays open forever.
• The advance refund is skipped. The advance and the final receipt then both count as turnover, so turnover is shown twice.
• A payment that arrived earlier is rung up with today's date. The PFR time is the time the receipt is issued and cannot be moved. If the money reached the account on Friday and you issue the advance receipt on Monday, the payment date goes into the ESIR time field, and, as we understand it, the receipt is issued no later than the next working day after the payment arrived.

How this works in Otkucaj

An advance is rung up with buttons that already carry the prescribed item names, so the code is never typed by hand and cannot be got wrong. A field for the ESIR time covers payments received earlier, for example a transfer posted the next day.

Closing is one button: the application issues the advance refund itself with the correct referent number and date and prepares the final receipt, leaving the cashier to fill in the real line items and issue it.

Otkucaj is an ESIR approved by the Serbian Tax Administration, record number 1667, classification 3. A new account starts in the test environment, where receipts are not fiscal; production requires your own security element and PAC.