About invoices

An invoice records a sale as a formal document: which products were sold, how much tax was charged, how much the customer paid, and whether stock should move. It ties together products, customers, inventory, fund accounts and tax, and it is where POS retail receipts land once uploaded to the back office.

1. Invoice types

• Standard invoice: an ordinary sales invoice with positive amounts; stock is decremented line by line when it is issued.
• Credit note: used for returns / reversals. It references the original invoice, has negative amounts, restocks the goods and refunds the customer. It uses its own number series.
• Simplified receipt (not yet enabled): a consumer-facing POS receipt / simplified invoice. The type is reserved and will be enabled when cash-register fiscalisation is integrated.

About the customer: consumer receipts are usually anonymous walk-ins that need no customer; when a customer wants a full invoice, the buyer’s tax id / name is entered (a saved customer, or typed inline). A full invoice requires buyer identity at issue; a simplified receipt may be anonymous. Buyer details are frozen at issue, so later renames don’t affect invoices already issued.

2. The five statuses

1. Draft — only this status can be edited or deleted.
2. Validated — the official invoice number is allocated, the lines are frozen and can no longer change; if the invoice moves stock, it happens now.
3. Partially paid — the customer has paid part of the amount but not all.
4. Paid — total paid ≥ total due.
5. Canceled — Draft / Validated / Partially paid can all be canceled; canceling returns any stock that was taken and voids any recorded payments.

A Paid invoice cannot be canceled directly. To reverse it, issue a credit note.

3. Where the line tax comes from

A line’s tax is not worked out on the fly at issue time. Instead the already-computed “net / tax / gross” from the product price is copied and stored, then multiplied by the quantity. So whenever you look back, the invoice’s figures match the original sale exactly; later re-pricing or rate changes never affect an issued invoice.

A product can carry both VAT and a surcharge (e.g. Spain’s RE). Both are charged on the same pre-tax base and added together — VAT is never folded into the surcharge.

4. Payments

Each time the customer pays, the system records an inflow on the fund account you choose, raises that account’s balance, and links the payment to the invoice. The invoice’s “paid” amount accrues, and the status moves to “Partially paid” or “Paid” accordingly.

• Multiple payments: you can collect in several instalments; they add up.
• Overpayment (change / prepayment): allowed; the status becomes “Paid”.
• Voiding a payment: handled by a fund red-reversal (a reversing transaction); the payment on the invoice is marked voided and the “paid” amount rolls back.

5. POS receipt upload

After a POS sale is finalised in-store (possibly offline), sales are uploaded to the back office asynchronously and in batches, and the server creates the invoice, records the payments and decrements stock.

• No duplicates: each receipt carries a unique key; re-uploading the same one simply returns the previous result, without decrementing stock or recording a payment twice.
• Stock moves on upload: because the upload is the only channel and it is asynchronous, stock is decremented when the upload arrives. If stock has already been sold to 0 by another channel by then, it can go negative — the sale physically happened and can’t be refused. Negative stock is the “oversold” signal for the back office to reconcile.
• Amounts kept as-is: each line uses the price and tax snapshot stored on the device; the server keeps it verbatim and does not recompute.

6. Invoice numbering

Invoice numbers carry legal and tax meaning: within a series they must be sequential, gapless and unique.

• The system uses a configurable number series that can number per store (e.g. FA-S01-2026-000123).
• Credit notes use a separate series.
• The number is allocated at the moment of issue; drafts use a temporary ref (e.g. PINV*****) beforehand.
• Whether to reset yearly, and the number format, are configurable per store.

Different countries have their own mandatory e-invoicing systems (Spain’s VeriFactu, Italy’s SdI, Poland’s KSeF, etc.). The system already reserves the matching fields so these can be adopted per country later, without changing invoices that have already been issued.