Standing collections
A debit-order run is CleverOps asking the bank for this month's invoices. Some control rooms collect the other way round: the debit-order instruction lives with a collections provider, at an amount fixed with them, and the provider debits each customer on its own day without being asked. Nothing is submitted from CleverOps — the money simply arrives, and the provider's wallet statement says who it came from.
CleverOps reads that statement, posts every collection against the right customer in one pass, re-opens what bounced, and shows you where the amount the provider collects has drifted from what you bill.
The supported provider is Corporate Collect. This sits alongside debit-order runs — a control room can use either, or both.
The rhythm
- Keep invoicing as usual. The monthly run raises the invoices. The provider collects on its own schedule.
- Import the wallet statement whenever new collections have come in — as often as you like in a month.
- Post the collections from Bank recon. One click, after a preview.
- Check collected against billed under Billing → Runs → Standing collections, and change any amount that has drifted at the provider before its next debit.
1 · Export the statement from Corporate Collect
Export Wallet Transactions for the month as CSV. Export the whole month to date, unfiltered, every time — CleverOps skips what it already has, so there is never a reason to work out where you left off.
2 · Import it
Go to Billing → Payments → Bank recon and click Import bank statement. Choose the file. CleverOps recognises the Corporate Collect export by its columns, so there is nothing to map. You're shown:
| Provider / Wallet | Corporate Collect and the wallet number the statement is of. Each wallet keeps its own import cut-off. |
| Collected | How many debit orders cleared, and their value. |
| Returned | Debit orders that cleared and then came back unpaid (DTO Late Failure). |
| Provider fees | Corporate Collect's own charges — per-item fees, failure fees, the monthly fee, validations. |
| Paid out | Money the provider moved out of the wallet — payouts to your bank and wallet transfers. |
| Wallet balance | The balance before the first line and after the last. |
Every wallet line carries a running balance. CleverOps checks that each line follows from the one before it, and refuses a file where it doesn't — a row left out of an export is a collection that would never be credited, and a customer chased for money they have paid. If you see This file has rows missing, export again without a filter.
On later imports it also checks that the statement picks up where the last one stopped. If it doesn't, export from an earlier date — the whole month is fine.
Click Preview, then Stage. A wallet statement is always staged whole. Provider fees, payouts and wallet transfers arrive already Ignored — they are never a customer receipt. Collections and returns wait in the queue.
Re-importing the same month is safe: every line is recognised and skipped, the same way a bank statement is (the cut-off and duplicate detection work identically).
A Debit Order Fail line with no amount — a debit order the bank refused before any money moved — shows as Skipped (Zero amount) in the preview and is not staged. Nothing was collected and nothing came back, so there is nothing to post.
3 · Post the collections
An ordinary bank line waits for a person to say who paid, because a bank narrative is not proof. A collections line is different: the provider states the customer's account code on every line. So these post together.
When collections are waiting, Bank recon shows a Collections feed banner. Click Post collections…. CleverOps first runs the whole pass and rolls it back, so the confirmation shows exactly what will happen:
| You'll see | What it means |
|---|---|
| Linked | The same money is already on the customer's account — captured by hand, or carried over from your previous system — for the same amount within three days. The line is linked to that payment. Nothing is created twice. |
| New debit-order payments | No such payment exists, so one is created (method Debit order) and applied to the customer's open invoices oldest first. Anything left over stays on the account as credit. |
| Returned | The payments from the original collection are marked Rejected, so the invoices they had settled re-open. An Accounts task is filed listing what came back. |
| Already reversed | The return was already put back on the account as a Returned payment debit carried over from your previous system. Nothing changes. |
| Need a customer | The reference on the line is nobody's account code. These stay in the queue. |
Click Post collections to do it for real.
How a line finds its customer
The line's reference is matched to a customer's account number — exactly as written first (M0169. and M0169 are different accounts), then without trailing dots or spaces, then as the parent of a sub-account code (B0015-2 → B0015). A reference that two customers could claim is left for you.
For a line that needs a customer, click Match, pick the customer, and post it (the method opens on Debit order). The feed remembers: next month that reference posts on its own.
Undoing
Every posted line shows under Matched with Undo match, and undo is always safe:
- a Linked line only lets go of the payment — the payment itself is untouched;
- a line that created its payment removes it, and the invoices re-open;
- a Returned line puts the payments it rejected back to cleared.
4 · Check what is collected against what is billed
Because the amount is fixed at the provider, it goes stale quietly: a price increase, a new site, a cancelled service all change what you bill while the provider keeps collecting the old figure. Billing → Runs → Standing collections sets one against the other.
It shows, per customer, what the provider collected in the latest month (net of returns) against what is billed. Choose what billed means:
- The monthly subscriptions — what the next invoice run will raise. Use this before a run, so amounts are right at the provider ahead of its next debit.
- An invoice run — the invoices that run actually raised.
| Verdict | Meaning | What to do |
|---|---|---|
| Matches | Collected exactly what is billed. | Nothing. |
| Cents apart | Within 5c — VAT rounding. | Nothing; not an instruction to change. |
| Collects less | The provider collects less than you bill. The account falls behind every month. | Raise the amount at the provider — or correct the subscription if it is wrong. |
| Collects more | The provider collects more than you bill. | Usually arrears being caught up on purpose; otherwise lower the amount. |
| Returned | The debit order came back unpaid this month. | Follow up; the invoices have re-opened. |
| Not billed | Collected, but nothing is billed to this customer. | Add the subscription, or stop the debit order. |
| Not collected | On the feed in an earlier month, nothing this month. | Check the mandate at the provider. |
The view opens on To attend to. Export list downloads the rows on screen — with each customer's provider reference and debtor id — to work through at the provider.
CleverOps reads the provider's statement; it does not send instructions to it. Amounts are changed in the provider's own portal.
Alongside your accounting package
Payments created from the feed are Debit order payments — and a payment the feed links to (one captured as an EFT before the provider's statement arrived) is corrected to Debit order too, because the method decides which account it posts to. A payment your accounting package itself entered is left as it was captured.
If you use the accounting sync, route the Debit order method to a clearing account under Where each payment method posts: the provider pays out lump sums net of its fees, so individual collections never match a line on your real bank statement. The cleanest set-up in Xero is a bank account for the provider's wallet (it needs no ledger code): each customer's collection posts to it against the invoice, and you import the same wallet statement into that Xero bank account to reconcile — collections match the pushed payments, the provider's fees are coded to bank charges, and its payouts become transfers to your real bank. The account's balance in Xero is then the wallet balance on the statement.
A collection that later comes back unpaid is marked rejected here, and the sync removes it from Xero, so the invoice re-opens on both sides.
One collection that settled several invoices goes to Xero as one payment per invoice, all on the same date; match them to the single statement line with Xero's Find & Match.
Permissions
Importing, posting and undoing need billing management access, the same as Bank reconciliation. The Standing collections view is on the Runs tab, which needs the same access.
Related
- Bank reconciliation — the queue these lines are staged in, the cut-off, and duplicate detection.
- Debit-Order Collections — the other arrangement, where CleverOps generates the batch.
- Monthly Billing Run — raises the invoices the collections settle.