Payments

What it does

Behaviours, not fields. Choosing between two modules is choosing between these.

Records what actually arrived, not what was invoiced. The gap between those two is where reconciliation goes wrong.

Fees are a column, so the missing euros have a name instead of being a rounding mystery.

Partial payments are recorded as they happen rather than forced into paid or unpaid.

Matches against Invoices on amount and payer, so settling one does not need doing twice.

How it works

1
A payment is recorded when it arrives, which is a different event from the invoice.
2
Net is derived, so the reconciliation figure cannot drift from its inputs.
3
Partial payments are recorded as they happen rather than forced into paid or unpaid.
4
Matching against Invoices settles the claim without doing it twice.

Best for

Comparing many records across many fields.

Not the right choice for

A phone. A table is the first thing that stops working narrow.

What a row holds

Every field, and what the agent listens for to fill it — which is the difference between a page you type into and one that fills itself.

Field	Type	Filled from
Receivedrequired	date	When the money actually landed, not when it was invoiced.
Fromrequired	text	Who paid, matched against Contacts where possible.
Grossrequired	money	The amount the payer sent, before any provider fee is taken.
Fee	money	What the provider took. Where the missing euros go.
Netrequired	money	What arrived. Derived from gross minus fee.
Method	text	How, including partial, which is a real and common state.

What it does not do

A module chosen for something it cannot do costs more than one that was never offered.

No payment processing. This records what happened elsewhere.
Fees are entered or imported; nothing calculates a provider schedule.
One currency, with the same silent-wrong-total risk as everywhere else in this category.
No refunds or chargebacks as first-class states.

Before it works

What you have to provide, if anything.

Record the fee. Without it the net figure is the gross figure and reconciliation fails.
Pair with Invoices and Cashflow, which both read from this.

In practice

A shop taking card, cash and transfer, reconciling a provider payout weekly.

“Lauret paid sixteen hundred, part payment on the invoice.”

What was said to the agent

What the agent built

A payment of 1,600, no fee, marked as partial against INV-0148, which stayed open for the remainder.

What changed

The weekly payout stopped needing a spreadsheet. Card fees came to 63 euros that month, which had never been a visible number.

Better with

These do a different job on the same data. An agent can have all of them.

InvoicesLive

The agent bills clients or is billed by suppliers, and someone needs to see what is unpaid without opening the accounting tool.

OrdersLive

Things are sold and then have to be prepared, shipped or collected, and several are in flight at once.

CashflowLive

Income arrives unevenly, costs do not, and someone needs to see a shortfall before they are in it.

Questions

What data does the Payments page use?

It reads payment records the agent has collected. Transactions and receipts. Nothing has to be imported first — the page appears once there is something to show.

Do I have to build or configure it?

No. You describe what you need in a sentence and the agent chooses the view and fills it. Custom pages exist for the cases no built-in view covers, and those are reviewed before they go live.

When is a table the wrong choice?

A phone. A table is the first thing that stops working narrow. It is best for: comparing many records across many fields.

Does it stay up to date?

Yes. The page is a view over the data rather than a copy of it, so anything the agent learns afterwards shows up without a rebuild or a re-import.