Bank reconciliation
Instead of copying receipts out of your bank's portal one at a time, upload the statement. CleverOps reads it, refuses anything from a period you have already reconciled, and puts the rest in a queue where you match each one to a customer.
Find it at Billing → Payments → Bank recon.
An imported statement line is not money in CleverOps. A bank narrative like EFT 4471102 is not proof of who paid, and crediting the wrong customer both wipes a real debt and keeps chasing someone who has already paid. Every line waits for a person to confirm the payer before it becomes a payment.
Which file format to export
Two formats are supported, and the choice matters more than it looks.
| OFX / QFX | CSV | |
|---|---|---|
| Column mapping | none needed | you map (auto-filled) |
| Dates | stated unambiguously | read day-first, could be guessed wrong |
| Money in vs out | stated by the bank | inferred from the columns |
| Duplicate detection | the bank's own transaction ID | our date + amount + description fingerprint |
| Which account it came from | in the file | you type a label |
| Closing balance | in the file | not carried |
| Availability | depends on your bank | every bank |
Prefer OFX where your bank offers it. It removes the three things CSV forces CleverOps to interpret: the date, the sign, and whether a line has been seen before. Look for it on your bank's statement-download screen, sometimes labelled for accounting software, Quicken or MS Money.
CSV remains fully supported and is the right choice when OFX isn't offered — it works on a statement from any bank.
If a provider such as Corporate Collect runs your debit orders itself, its Wallet Transactions export is imported here too. CleverOps recognises it on its own — there is nothing to map — and because each line names the customer's account, those lines post in one pass instead of one confirmation each. See Standing collections.
Some banks truncate the payer name in OFX and drop the payment reference. Because the strongest way CleverOps identifies a payer is an invoice number in the reference, an OFX file can occasionally produce weaker suggestions than the same bank's CSV. If your matches get worse after switching, that's why — compare one statement in both formats and stick with the better one.
Importing a statement
Click Import bank statement (on either the Payments list or the Bank recon view).
1 · Choose the file
Select the .ofx, .qfx or .csv file. CleverOps detects which it is.
2a · OFX — confirm the statement
There is nothing to map. You're shown the account, the statement period, the closing balance and the currency, straight from the file. If the file covers several accounts you pick which one to import — each account is imported separately so their cut-offs stay independent.
2b · CSV — map the columns
CleverOps auto-maps the common column names, including headers padded with currency or account noise (Credit Amount (ZAR)). Check the mapping and correct anything it missed.
| Column | Needed | Notes |
|---|---|---|
| Date | Yes | Read day-first (03/04/2026 is 3 April). ISO dates, compact 20260403, and named months (03 Apr 2026) are all understood. |
| Description | Yes | The statement narrative. |
| Reference | No | The payer's reference — the strongest matching signal there is, so map it if your bank provides it. |
| Amount (signed) | One of these | A single column where money out is negative. |
| Debit / Credit | One of these | The two-column shape. Money in must end up positive. |
| Balance | No | The running balance, kept for reference. |
Statements come in one shape or the other; map whichever yours has. Money-out notations are all understood — a leading minus, accounting parentheses (1 234.56), a trailing minus 1234.56-, or a value in the Debit column.
There's also an optional Bank account label. You only need it if you bank into more than one account: each label keeps its own import cut-off. A CSV doesn't say which account it came from, which is one of the things OFX does for you.
3 · Review and stage
Every row is classified before anything is written:
| Status | Meaning |
|---|---|
| New | Will be staged for review. |
| Already imported | This exact line is already in CleverOps — it is skipped. |
| Before cut-off | Dated behind the point this account is already reconciled to. Refused — see below. |
| Repeat | A second identical line on the same day. Treated as a real second payment, not a duplicate — but flagged so you can check. |
| Skipped | Unreadable date or amount, or a zero-value line (an opening balance or a heading). |
Untick Also stage money-out lines if you only want receipts. Withdrawals are staged by default so the statement reconciles as a whole; they can never be posted as a customer payment.
Click Stage N transactions to write them.
The import cut-off
Every bank account has a cut-off: the latest transaction date already staged for it, shown at the top of the review step.
Lines dated before the cut-off are refused outright. CleverOps does not try to work out whether an old line is a duplicate — behind the cut-off, the period is closed. That makes re-importing a reconciled month impossible rather than merely unlikely, which matters because the alternative is crediting a customer twice.
So the normal rhythm is: export from where you left off, upload, and any overlap you happened to include is dropped without you having to think about it.
The cut-off day itself stays open. A bank posts transactions all day and a statement whose last day is partial is completely normal, so new lines dated on the cut-off are still accepted — closing that day too would silently discard the rest of it forever. Lines on that day are still protected by duplicate detection.
Each account has its own cut-off, so reconciling one account never closes a period on another.
Loading an earlier period on purpose
If you genuinely need to load history from before the cut-off — a first-time back-load, or a correction — tick Load an earlier period (back-fill) on the review step. It is off by default, and:
- duplicate protection still applies, so nothing already imported can come in twice;
- the closed-period guarantee does not apply to that file, and that is recorded against the import, so you can always see which file was allowed behind the line.
How duplicates are detected
OFX uses the bank's own transaction ID (FITID), scoped to the account. That is authoritative: two identical payments on the same day are told apart by the bank, not by us.
CSV has no such ID, so each line gets a fingerprint from its date, signed amount, description and reference, with punctuation and spacing ignored so two exports of the same statement still match. Two identical payments on one day are counted as two transactions, not one, so a customer who pays the same amount twice is not silently short-credited.
The one case the CSV fingerprint can get wrong is a statement that starts part-way through a run of identical lines on the cut-off day: the repeat is then flagged Already imported. That errs toward importing too little rather than crediting twice — tick import anyway on the row to bring it in. The cut-off means this can now only ever arise on that single boundary day.
Working the queue
The Bank recon view lists the staged lines with four tiles across the top — Unmatched, Unmatched receipts (the money-in value still to post), Matched, and Ignored. Click a tile to filter to it, click again to clear. Search matches the description and reference; Money in only is on by default.
Suggestions
For each unmatched receipt CleverOps proposes a payer, in this order of confidence:
- Invoice number in the reference — the customer quoted the invoice number. This identifies the invoice and the customer outright.
- Payer name in the narrative — identifies the customer. The invoice is only suggested too when exactly one of their open invoices owes precisely this amount; with several open, choosing is left to you.
- A uniquely matching amount — exactly one open invoice in the whole control room owes this amount. If two or more do, nothing is suggested rather than a coin flip.
A suggestion pre-fills the pickers. It is never applied on its own.
Matching a line
- Click Match on the row.
- Confirm or change the customer who paid.
- Optionally pick an invoice to settle. Leave it blank to bank the money as account credit.
- Choose the method (EFT by default).
- Check the summary and click Post as payment.
The payment is created with the statement's date and reference, and a note recording which statement line it came from. If you picked an invoice, the money is applied to it under the same rules as applying credit by hand — capped at what the invoice owes, with any surplus held as account credit.
Post the line against the largest invoice it should cover. The surplus becomes an unallocated payment, which you then Apply to the next invoice from the Payments tab — repeating until the deposit is used up. Every part stays linked to the original bank line, so the deposit can always be reconstructed.
Ignoring a line
Bank charges, internal transfers, interest and your own payments out are not customer receipts. Click Ignore to set the line aside; it leaves the unmatched count without pretending to be money. Restore puts it back in the queue.
Matching a bank line always creates a new payment. If someone had already keyed that EFT in on the Payments tab, matching it again credits the customer twice. When you recognise a line you have already captured, click Ignore — the payment is already on record and the bank line has done its job.
Undoing a match
Click Undo match on a matched row. The payment created from that line is deleted, any invoice it was settling re-opens, and the line returns to the queue. The deletion is recorded in the audit trail.
A collections-feed line that was only Linked to a payment already on the account is different: undoing lets go of the payment without touching it.
Use Undo match when the money was credited to the wrong account. If the payment genuinely bounced or was reversed by the bank, mark it Rejected on the Payments tab instead — that keeps the record and re-opens the invoice, which is what an auditor expects to see.
Using this alongside Xero (or another accounting package)
Bank reconciliation does not replace or block the accounting sync. Both work at once — but they overlap, so decide which side owns bank matching before you start.
Payments already sync both ways: a payment you record in CleverOps against a synced invoice is pushed to Xero, and a payment entered in Xero is pulled back. The sync already avoids the obvious duplicate — a Xero payment that matches an unlinked CleverOps payment on the same invoice for the same amount is linked to it rather than imported again.
Xero has its own bank feed, so if you also import the statement here, two systems are looking at the same deposit. Pick one:
| Match bank lines in CleverOps | Match bank lines in Xero | |
|---|---|---|
| Where you work | Bank recon, against invoices raised here | Xero's reconcile screen |
| What flows | payments push to Xero | payments pull into CleverOps |
| Good when | CleverOps raises the invoices and you want debtors current here | your bookkeeper lives in Xero |
Whichever you choose, in Xero the CleverOps payment and Xero's own statement line are matched off against each other — that is Xero's normal reconcile flow, not a duplicate.
Don't match the same deposit on both sides. If you post a bank line here and reconcile the same line to a separate payment in Xero, you end up with two payments for one deposit. Ignore the line in whichever system is not the owner.
A split deposit can defeat the automatic de-duplication. When one deposit is capped at an invoice's balance and the surplus is split off as account credit, the CleverOps payment is smaller than the deposit. The sync matches a Xero payment to a CleverOps one on same invoice and same amount, so a split amount will not match and the Xero payment can be pulled in as a second payment. If you split deposits across invoices, match those bank lines on one side only.
Permissions
Importing statements, matching, ignoring and undoing all require billing management access — the same permission as recording a payment by hand. Staff without it cannot see the Bank recon view.