Invoicing provider

Settings › Setup › Invoice decides who issues the project's invoices: the platform's built-in numbering, or an installed invoicing module (an accounting service such as Fakturoid, connected through Modules).

Choosing the provider#

The Invoicing provider select lists Platform (built-in) and every installed module that issues invoices. A module that is disabled or not yet verified is listed but cannot be picked — open it on the Modules page and run Verify first. Only the project's owner or an admin can switch; the switch is saved at once (it is not part of the section's Save) and recorded in the Provider history table: when, to which provider, the last built-in number at that moment, and who switched.

Before it switches, the console asks you to confirm and tells you what is still in flight:

• invoices still pending at the previous module stay with it — retry or reassign them from the order page;
• for a module target, running Stripe subscriptions that renew from their first-period snapshot are counted, because their renewal invoices may not follow a changed plan.

Switching back to Platform continues the built-in sequence; a number the module already used is skipped automatically.

With a module#

While a module issues the invoices, the built-in fields (number mask, last number, default note, template, due days) have no effect and are hidden. Two things remain:

• Invoice delivery — who e-mails the buyer: the project (the platform's own invoice e-mail, which then links the provider's document) or the invoicing module (the provider's own e-mail; the platform sends nothing). Saved with the section.
• the module's own configuration card, the same one as on its module page.

The module's document is the legal one. Under Shop › Invoices such an invoice shows an Issued by a module card instead of the template preview: the number as the provider printed it, the status the provider reports (Issued, Paid, Cancelled) with the paid date, the payment instructions it printed, any warnings, and the links Open document (the public page the buyer gets) and Open in {module} (the provider's back office). Send to customer asks the module to send it when the module delivers, otherwise sends the platform e-mail. Every existing invoice link (…/invoice?store=…&invoice=…) keeps working: for a module-issued invoice it forwards to the provider's document, or downloads its PDF.

When an issue does not go through#

The platform asks the module once, when the order completes (or a subscription period renews). Until the module answers, the order's Invoice card shows the pending invoice:

• Waiting for the provider — the call is running; The provider did not answer after two minutes;
• The provider call failed — with the provider's error and whether it thinks a retry may help.

The platform does not call again by itself. Retry now repeats the same request to the same module (it cannot create a second invoice for the same sale). Reassign (owners and admins) issues the invoice through the project's current provider instead — use it when the old module is gone; check the old provider first, it may already hold a document for that sale. A module can also report an invoice it created after a time-out; it then appears on the order by itself.

Payments the provider pairs (e.g. a bank transfer matched to the invoice) mark the invoice Paid and settle an order paid by transfer or cash. How the payment reaches the project (a webhook the module registers, or a daily check) is in the module's own Documentation tab on its page — for Fakturoid, the section Payments in: webhook or daily check.

Proformas (bank transfer)#

A buyer who pays by bank transfer needs to know where and how much to pay before you ship. Below the provider, the Proformas block turns that on:

• Issue proformas — the opt-in. Only while it is on (and the invoicer can issue proformas) can Payments offer Bank transfer at checkout. With a module that does not issue proformas the box is disabled and says so; with the platform, the vendor details need a bank account.
• Due in days (default 14) — when the transfer is due.
• Grace days (default 3) — how long after the due date an unpaid order waits before it is closed (and its proforma cancelled).
• Proforma number mask (default ZF-YY-nnnn) and Note — the built-in series only; a module numbers its proformas in its own series (Fakturoid: Settings › Number series in Fakturoid).

What happens to a bank-transfer order:

1. When the order is confirmed, the proforma (zálohová faktura) is issued: number, amount, account / IBAN, variable symbol, due date and a QR payment code. The buyer gets it by e-mail (the project's proforma e-mail, or the module's own when it delivers) and on the shop's thank-you page.
2. When the payment arrives — paired by the module, or Mark paid on the order — the proforma turns Paid, the order moves to Ready and the final invoice is issued right away (with Fakturoid it is the paid invoice Fakturoid issues from the proforma). Completing the order later issues nothing more.
3. Not paid by the due date + grace days: the order is closed and the proforma cancelled. A payment that still arrives afterwards does not reopen the order — the Payment card shows it as paid after the order closed.

The order's Invoice card shows the proforma above the invoices — number, status, amount, VS, due date, a link to the document and Resend (an unpaid proforma the project mails). A failed proforma call shows like a pending invoice, with Retry now.

Issue proforma on the order's Payment card does the same by hand for a business customer who pays before you ship: an unpaid Confirmed or Ready order (cash, cash on delivery, in person or none) switches to bank transfer, with an optional due date. Cash on delivery itself needs no proforma — the carrier collects the money and the invoice comes, already paid, when the order completes.