Skip to main content

Wired Payments

What it is​

The queue of receipts recorded as in transit. A payment entered on Reconcile Payment with the status Wired (In Transit) lands here and stays until somebody says whether the money actually arrived.

The distinction is real, not cosmetic. invoice_balances — the view every outstanding figure is built from — counts a payment toward amount_paid only when its status is received (or is null, for the older rows that predate the column). A wired payment is totalled separately as amount_wired and does not reduce what the client owes.

So: confirming here is what actually credits the invoice. Rejecting leaves the invoice outstanding, which is the correct outcome for a transfer that never landed.

Who can open it​

Needs the finance.payments feature grant while FEATURE_GRANULAR_RBAC is on; the owner bypasses it. With the flag off, any signed-in account can reach it by URL.

Before you start​

"Pending Pipeline" adds currencies together and labels the result USD

The headline figure is every wired payment summed as plain numbers and then formatted as US Dollars. If any of the pending transfers are in another currency, that number is not money in any currency.

The per-row Amount column is correct — each row is formatted in its own invoice's currency. Read the rows, not the headline.

The list follows the entity switcher. payments has no entity_id of its own, so the screen joins through the invoice and filters on invoices.entity_id. A transfer you cannot find is usually filed under another entity.

At most 500 payments are loaded, newest first, and the search and filter run over those 500 only.

Confirming records who did it. confirmed_at and confirmed_by are stamped with your email address. Rejecting records neither.

Every control on the page​

ControlWhat it does
← Back to LedgerReturns to SOA
View CategoryFour buttons — wired, received, rejected, all. Opens on wired, so the first thing you see is the pending queue, not everything
Search TransfersFilters the loaded rows as you type. Matches reference number, client name and invoice number — not entity, not amount
ConfirmOn a wired row only. Asks "Are you sure you want to confirm receipt of this payment?"
RejectOn a wired row only. Asks "Are you sure you want to reject this payment?"

The table — Counterparty / Entity, Reference / Invoice, Date, Amount, Status, Control Actions. No column is sortable. Rows are always newest payment date first.

A row that is already received shows ✓ Verified and a rejected row shows ✗ Rejected, in both cases with no buttons: a decision cannot be changed from this screen.

What it writes​

Both buttons UPDATE payments for that one row:

  • Confirm sets status = 'received', confirmed_at to now and confirmed_by to your email address. The invoice's outstanding balance drops by the amount, everywhere — SOA, invoice list, aging.
  • Reject sets status = 'rejected' and nothing else. The invoice stays outstanding.

Nothing is deleted. A rejected payment keeps its row; it simply counts toward neither amount_paid nor amount_wired.

🔴 There is no way back. Neither status offers a button, and nothing else in the app moves a payment out of received or rejected. A wrongly confirmed transfer has to be corrected through the invoice or a credit note.

When it goes wrong​

"No matching transfers found" and you expected one. Three things to check, in order: the View Category buttons still open on wired, so a confirmed payment is hidden until you press all; the entity switcher scopes the list; and only the most recent 500 payments are loaded.

A payment is here that should not be. It was recorded with status Wired (In Transit) on Reconcile Payment. Reject it — that leaves the invoice outstanding, which is what you want if the money never came.

The client says they paid but the invoice still shows a balance. Expected if the receipt is sitting here unconfirmed. A wired payment does not reduce the balance; confirm it.

"Update failed: …" The status change did not save; the row is unchanged. Retry, and if it persists the message is the database's own.

Pending Pipeline looks wrong. See the warning above — it sums across currencies.