Payables lifecycle
A payable is described by three independent layers. They don't replace one another — they coexist, and the screen shows all of them:
| Layer | What it answers | Where it shows |
|---|---|---|
| 1. Bill status | Where the bill sits inside Smart Finance (Draft → Pending → Paid) | "General status" column |
| 2. Authorization | Has a person released this payment? (the entry gate) | Badge next to the general status |
| 3. Gateway status | If it was sent to the bank, where it stands there | "Gateway status" column |
Layer 3 only exists if the bill was sent to the bank. In the list it has a column of its own: "General status" and "Gateway status" sit side by side, both sortable — the gateway is never a chip hanging off the bill status. They are two distinct signals: one says what Smart Finance knows, the other what the bank reports. Off the gateway track, the column shows "-".
What appears next to the general status is layer 2: the authorization badge. And on the detail screen the gateway status isn't in the header — it lives inside the gateway card.
Layer 1 — Bill status
| State | Description |
|---|---|
| Draft | Created but not published. Doesn't count toward the totals. |
| Pending | Confirmed, awaiting payment. |
| Paid | Linked to a transaction. |
| Cancelled | Voided, generates no movement. |
The column also shows a fifth badge that is not a state: Overdue — any Pending bill whose due date has passed. It is derived from the date, not stored: nothing "becomes" overdue, and paying or rescheduling makes it disappear on its own.
- Publish (Draft → Pending): confirms the bill — but it still goes through layer 2.
- Mark as paid (Pending → Paid): there are two routes — see "How a bill becomes Paid", below.
- Cancel (Pending → Cancelled): voids it. It only shows on a pending bill, and it is not irreversible — the dialog says "You can reopen it later by editing the status."
Layer 2 — Payment authorization
An anti-fraud gate: a bill created through the form, CSV or API does not enter the official list until a person authorizes it in Authorize payments (/payables/authorizations). The gate is a workspace setting, on by default; turned off, created bills are born official and skip the queue.
| State | Meaning |
|---|---|
| Awaiting authorization | Waiting for someone to authorize it. Outside the official list — it counts toward neither the totals nor the cash flow, and it can't go to the bank. |
| Authorized | Released — it enters the official list and becomes eligible to be sent to the bank. |
| Rejected | Blocked for good. |
| (no badge) | Born official, without going through the queue. |
The gate applies to whatever comes in the front door: the form, CSV import and the API. Born official, without authorization are the bills the system itself generates from something already decided earlier — the installments of an existing recurrence and whatever comes in from Fintera.
Saving as a draft doesn't dodge the gate. A draft carries no badge because it isn't an obligation yet — but publishing is the moment it becomes one, and that's when it joins the queue, like any bill created directly. A draft is not a shortcut.
While it awaits authorization, the manual "Mark as paid" disappears too — the bill isn't official yet.
Layer 3 — Gateway status
This only comes into existence after the bill is sent to the bank. It mirrors the payment's real state on the gateway — from Pending and Awaiting approval through to Confirmed, by way of Scheduled, Awaiting funds and the like. The full list, with what each one means, is in Sending to the bank.
"Approved" is not the end. It means the batch was approved — the institution has not confirmed yet. What closes the cycle is Confirmed. The final states are Confirmed, Canceled, Rejected, Reproved and Failed.
"Send to the bank" is not a row action in the list. It exists in two places, both on the detail screen: the header and the gateway card. From the list, the route is "Send payments", in the header — the inbox that dispatches in batch.
How a bill becomes Paid — two routes
There are two routes to a paid bill, and they are mutually exclusive.
Manual route — the payment happened outside
You paid the bill outside the system (internet banking, cash, petty cash…). Use "Mark as paid":
- Enter the payment date and the financial account used.
- The system marks it Paid and creates the outgoing transaction in that account.
- Interest and discounts can be recorded at settlement.
Gateway route — the system did the sending
You clicked "Send to the bank". From there on you don't settle it — the system does it on its own:
- When the gateway reaches Confirmed, the bill is marked Paid automatically and the outgoing transaction is created in the source account.
- That's why, on the gateway route, the "Mark as paid" button disappears — it's what prevents a double settlement.
Requirement for automatic settlement: the source account ("Pay from") must be set. Without it the system has nowhere to post the outflow and does not settle — the bill stays Confirmed and open (see below).
When "Mark as paid" comes back
If the dispatch finished and the bill was still left open, the manual button is re-exposed so you can close it outside:
- Confirmed with no source account — the bank confirmed, but the system had nowhere to post it.
- Canceled, Rejected, Reproved or Failed — the payment never went through; it has to happen outside.
The full flow
Draft is an optional detour, not the front door. Creating through the form, through CSV or through the API writes the bill straight to Pending and awaiting authorization. Only clicking "Save draft" routes you through there — and publishing from there lands on the same gate, it doesn't skirt it.
Create a payable
- Go to
/payables/new. - Fill in the required fields: Amount (R$), Due date, Description, Supplier, Accrual month and Type.
- Set the operation type and the document — see Operation and payment. Category and classification center are optional.
- Finish with Add bill, Add and create another or Save draft.
The supplier is not optional. Without it the form won't submit: "Selecione ou crie um fornecedor". You can pick an existing supplier or type a new name — in which case it gets registered along with the bill.
Company is required too, but it isn't a form field: it comes from the header selector.
"Publish" does not exist on the create screen. The buttons there are the three above. Publish shows up only on the detail screen, and only while the bill is a draft.
Either way, the bill enters under authorization (layer 2) before it counts toward the numbers.
Edit
A paid bill is not read-only. There is no lock by state: the form opens normally in any status, including Paid.
The real lock is a different one, and it comes from the bank — not from the bill's state. When the gateway reaches Confirmed, part of the form closes, and the screen warns you:
"Payment confirmed by the bank. What describes the payment — amount, due date, supplier and the payment information — can no longer be changed. Internal classification (category, center, attachments, notes) stays editable."
In other words: the lock is partial, and it has a reason. It freezes what describes a bank transaction that has already executed — amount, due date, supplier, "Pay from", operation type, document and the payment coordinates. What stays open is what describes how you classify it: category, center, accrual month, description, attachments and notes. Classifying is accounting work that carries on after the money leaves.
The lock isn't just cosmetic. The server refuses changes to those fields even over the API — the screen disabling the fields is the courtesy; the rule holds from any door.
This lock does not exist on receivables — they never go through a dispatch to the bank.
When editing a bill that belongs to a group, the system offers "Apply to other installments", showing you exactly what will change first. That means all the installments in the group — including the ones before the one you're editing, not just the ones after. Only the already-settled ones and the edited installment itself are left out. The selection comes fully checked; uncheck whatever shouldn't inherit.
Delete
On a bill that belongs to a group — installment or recurring — deleting asks about the scope:
- Delete only this one
- Delete this and future ones
The same selector covers both cases: what it looks at is the group, not the type. On a standalone bill it doesn't appear.
The selector exists in the list. Deleting from the detail screen always deletes just that one bill, without offering the scope.