About payment methods

Brix supports the following payment methods:

Cash
Cheque
Card
Bank Transfer
Paypal/PaymentGW
Cash on Delivery (COD)
~~Nature~~
Room No.
Other
Used when the payment method is none of the above or when an invoice is paid with several different payment methods. For such invoices all individual payments must be entered directly in the till payments form, each time linking them to the same invoice.
Compensation
Entered as a bank transfer payment.

1. Availability of payment methods per department

Which of the listed payment methods are actually offered in POS sales, invoices, quotes and till payments depends on the department. The list is defined in the ~ PAYMENT METHODS ~ tab of the Departments form — see ~ PAYMENT METHODS ~.

When Brix fills in the payment method, bank account and card company itself and when it asks the user to select them is described in Automatic filling of the payment method, bank account and card company.

2. Payment method and fiscalisation

The payment method is one of the criteria by which Brix decides which protocol an invoice is sent to fiscalisation with — F1 or F2.0. The rules are kept in one place, in Sending invoices to F1 or F2.0 fiscalisation, and are shown here by including that text:

Who issues paper invoices and until when is described in paper_invoices.

If the company has the EP_IRA setting enabled, the system applies the F2.0 protocol first when an invoice is approved. This applies to all invoice subtypes, including the sale of fixed assets. Companies without this setting cannot send eInvoices.

To send eInvoices the company contracts an information intermediary — Moj eRačun (MeR) or ePoslovanje (Pondi); the contracting procedure is described in mer and eposlovanje. Support enters the intermediary's credentials into Brix based on a support request. Fiscalisation under the F1 protocol requires a FINA certificate, see the fiscal tab.

Sending is automatic. When an invoice is approved, the system itself sends it for fiscalisation and delivery to the customer — after that the invoice is not resent manually.
Manual sending is used only to send a copy of an invoice already sent, as described in Resending an invoice to F2.0 fiscalisation.

The Fiscalisation 2.0 and eReporting system aims at real time. An eInvoice dated more than 15 days ago will pass through the system, but it may become a “red flag” in an audit, because an eInvoice must be issued at the moment of the business event or very soon after it.

Exception — F1 fiscalisation
The F1 protocol is applied automatically in the following cases:

Citizens (natural persons)
The invoice is fiscalised under the F1 rules for all payment methods. The obligation to send also depends on the {Delivery Territory} field — only Domestic delivery is fiscalised, see ~ BASIC ~.
Legal entities
The invoice goes to F1 fiscalisation if the payment method is Banknotes and coins or Card, provided that the {Delivery Territory} field is set to Domestic.

In all other cases — including legal entities paying by Bank Transfer — the invoice is sent under the F2.0 protocol.

An invoice that was not sent to F1 fiscalisation automatically is sent manually with the F1 button on the ~ BASIC ~ tab. The button is not shown on invoices sent under the F2.0 protocol.

Under the Fiscalisation 2.0 rules an eInvoice is sent to legal entities only. Invoices issued to natural and temporary persons cannot be sent as eInvoices — they go to fiscalisation under the F1 protocol. The exception are natural persons registered in AMS, see Invoices to natural persons registered in AMS.

The list of payment methods and their meaning is described in About payment methods. Which payment methods are available in a department is set in ~ PAYMENT METHODS ~. Partners subject to public procurement also receive the {FINA ID} with the eInvoice.

Every eInvoice line must carry a Classification of Products by Activity (KPD 2025) code of at least six digits; see KPD (Croatian Classification of Products by Activity).

Checking whether an invoice was actually fiscalised under F1 is described in fis1check. Payment of invoices sent under F2.0 is reported automatically, see eReporting of invoice payments; advance payments are handled in rappf2.

Customer did not receive the eInvoice

Whether an eInvoice was delivered to the customer is checked on the intermediary's portal, with the username and password received from it. Report the error to the intermediary's technical support, stating that you use the MICRO PROCESS software. Forward the reply you receive, with the invoice number, to us as a support request.

Attachments with an eInvoice

All documents in the invoice's ~ DMS ~ tab at the moment of approval are sent with the eInvoice. The rules and limitations are described in Sending attachments with an eInvoice.

The split “is fiscalised / is not fiscalised” by payment method applied before the introduction of Fiscalisation 2.0.

From 01.01.2026 invoices issued to consumers (B2C) are fiscalised regardless of the payment method, and eInvoices under the F2.0 rules are sent to legal entities also regardless of the payment method. The payment method no longer decides whether an invoice is fiscalised, but which protocol it is fiscalised with.

For invoices issued to natural persons the obligation to send to F1 is additionally determined by the {Delivery Territory} field — see ~ BASIC ~ and fis1check.