Debit-Order Collections
Debit-order collections automate the VCR → customer side of billing for customers who pay by debit order. Instead of recording each payment by hand, you generate a collection run for a date, export a bank file to submit to your bank (Netcash, or ABSA Online Collections), and then reconcile the bank's results in one pass — cleared collections close their invoices, and returns re-open them for follow-up.
Find it under Billing → Runs, in the Debit order runs view (next to Invoice runs, which raises the invoices these runs collect).
Everything on this page is for collections CleverOps generates — a run, a bank file, a reconcile. If the instruction lives with a provider such as Corporate Collect, who debits each customer on its own day at a fixed amount, nothing is generated here at all: import the provider's wallet statement instead. See Standing collections.
Before you start
A customer is collected on a given date only when both of these are true:
- They have at least one active subscription set to pay by Debit order with a collection day of month (set on the subscription — see Subscriptions). A site subscription with no customer of its own counts for the site's customer — only when that customer belongs to your control room.
- They have banking details on file (an active mandate). Without banking, the customer's invoices still appear in the run but are flagged No banking and excluded from the bank file until you add their details.
A subscription set to collect on the 31st is collected on the last day of any shorter month automatically.
Banking mandates
Each customer has one active mandate holding their account holder, bank, branch/universal code, account number, and account type. Manage it from the Debit-order mandate card on the customer's Billing tab, or from the Add banking button next to any flagged item (in a preview or a run) — both open the same Banking details dialog. Saving replaces the customer's current active mandate; the previous one is retained for audit.
Debit-order batches — a range of days as one draft
Most months you want the same thing for everybody: collect this month's subscription from every debit-order customer, on each customer's own collection day, and hand the bank one file. New batch… on the debit-order runs list does exactly that, and lets you change any account before anything goes to the bank.
- Click New batch… — anyone with billing management access can run a batch end to end (no super-admin mode: a batch creates no payment records; only reconciling does). The dialog opens on next month, 1st to last day.
- Collection days — From / To: the days to collect on (up to two months). The dialog lists every day in the range that has debit-order customers due, with how many. A day that already has a run is shown greyed and left alone — discard that draft first to rebuild it.
- What to collect:
- Subscriptions only — each account's subscription on this period's invoice. Overdue amounts from earlier months and once-off charges are left out and stay with payment reminders.
- Everything due — every open invoice dated up to the end of this period: the subscription, once-off charges and anything overdue.
- Include payment-arrangement instalments — on by default. Untick it to leave every arrangement instalment out of the batch (an account you later set to Everything due gets its instalment back).
- This period's invoices — Dated from / Dated to: which invoice dates count as "this period". It follows the collection days until you change it; anything dated earlier counts as overdue. If you invoice before the month starts (say on the 25th), move Dated from back to that day.
- Click Create draft. One run is generated per collection day, and every account is answered with your choice. An account's own standing rule still wins — Never debit collects nothing, Capped per run keeps its cap, Plan only collects subscriptions only, Collect everything open collects everything due, and Always review is left unanswered for you.
Until a month's bank results are recorded here, its invoices still read unpaid. With Everything due picked, the dialog warns when the month before the batch has no reconciled run — collecting "everything" then would debit last month a second time. Import the bank's results first (for ABSA, Import ABSA batch report), or collect Subscriptions only.
The draft
The draft opens straight away — and a draft left open is the batch's row on the runs list, marked Draft; click it to carry on. It is one sheet for the whole range: one row per account per collection day with its Subscription (this period), Overdue (older balances — greyed while they are not being collected), Instalment, To debit (what goes in the bank file), Bank (bank and last four digits) and Answer. Tiles above it total what will be debited and how many debits that is, this period's subscriptions, the overdue on these accounts (and how much of it is being collected), and the accounts with no banking, which are never in the file.
- Filter with the chips — Has overdue, Instalment, No banking, Skipped, Needs an answer, Changed by hand — or search by customer name or account number.
- Change one account with its Answer list: Subscriptions only, Everything due, Custom amount… or Skip. A custom amount is the total to debit for that account — any instalment is part of it and always collects. The account's lines are rewritten on the spot.
- Change many at once: tick rows (the header box ticks every row showing), then choose Subscriptions only, Everything due or Skip on the bar that appears.
- No banking? Click Add in the Bank column; once the banking is saved the account is re-answered so its debit joins the file.
- Download list (CSV) gives the whole sheet — reference, customer, day, subscription, overdue, instalment, to debit, bank, answer — for a second pair of eyes before anything is sent.
When the sheet is right:
- ABSA control rooms — Approve & build ABSA file: every run in the draft is approved (anything still unanswered collects subscriptions only, or approval stops in Strict review mode), re-checked against live invoice balances, and built into one
CL‹user code›.trfcovering every day. The file downloads and the runs are stamped Exported. Upload it at ABSA, then import ABSA's batch report when the results are back. - Other control rooms — Approve batch: every run is approved and goes to the bank on its collection day like any approved run.
- Discard draft throws the whole draft away — nothing was sent to the bank, and you can create a new batch straight after. (A run whose pre-debit notice email had already gone to a customer is cancelled instead of removed, so the record of what they were told survives.)
Changing any answer re-opens approval, exactly as in a single run's review. Each day of the draft is also an ordinary run underneath, so a single run's review, export and reconcile all still work on it.
The runs list shows batches
The list of debit-order runs has one row per batch, not per collection day: a batch made with New batch… is one row (October 2026 · Subscriptions only), and older runs are grouped by their collection month (July 2026). Each row shows how many collection days it spans, its status, the number of debit lines, the total, and — once the bank's results are in — what cleared and how many came back. The tiles above the list describe the latest batch.
Clicking a row opens it in a window:
- A draft opens the draft sheet above.
- A batch that has gone to the bank opens the batch window: the same totals, a Days tab (every collection day with its run, status, debits, total, cleared and returned — click a day to open that run) and an All lines tab (every line of every day, with its day). For ABSA, Download ABSA file again rebuilds the one
CL‹user code›.trffor the whole batch, and Import ABSA batch report records the bank's results. - A batch of one day opens that run directly.
A run opens in its own window too — its status, the bank file / Netcash / reconcile buttons, Cancel run (super-admin mode), and its lines: what is being collected first, sorted by customer with the invoice date, and underneath, folded away, the older invoices this run did not collect (N older invoices not collected in this run), each with its open balance and Not collected.
The collection workflow
1. Preview
Pick a Collection date and click Preview. This is read-only — nothing is collected or changed. It shows:
| Tile | Meaning |
|---|---|
| Customers | Debit-order customers with something due on this date |
| Invoices | Their open invoices that would be collected |
| Total due | The gross amount, and how much of it is banked |
| Missing banking | Invoices that will be excluded from the file until banking is added |
The per-invoice table lets you add banking for any customer flagged Missing before you generate.
A customer on an active payment arrangement is not collected at full balance for the covered arrears. Instead, the run adds instalment slices — oldest covered invoice first, capped at the agreed monthly amount — on top of their normal billing. These lines carry an Instalment pill in previews and run items, and the preview summarises the arranged total. Everything else about the run (bank file, reconcile, bounce handling) treats them like any other line.
2. Generate the run
Click Generate run and confirm. CleverOps creates a run with one item per open invoice, snapshotting each customer's banking details into the item so later mandate edits never change what was already collected. Invoices that are already queued in another live run are skipped, so you can't double-collect.
Previewing and batches are available to anyone with billing management access. Generating a single run and reconciling require super-admin mode — reconciling creates payment records.
3. Review & approve
A generated run opens as a collection review — one row per account (the bank debits an account; the customer experiences one hit), decomposed into Plan (this cycle's subscription amounts), Arrears (older open subscription billing), Ad-hoc (job / roster / manual amounts), and any Instalment from an active payment arrangement. Accounts that would be debited anything beyond their plan are flagged and need an answer:
| Answer | What it does |
|---|---|
| Plan only | Collects this cycle's subscription amounts (plus any agreed instalment). Arrears and ad-hoc amounts are not debited and roll to payment reminders. "This cycle" is the invoices dated in the batch's this period window for a run made by New batch…, and the 32 days before the collection day for any other run. |
| Collect full | Collects every open invoice at full balance. |
| Amount… | A one-off cap, spread over the oldest invoices first (on top of any instalment). |
| Arrange… | Creates a payment arrangement on the spot — the run immediately re-slices that account to the agreed instalment. |
| Skip run | Nothing is collected from the account this run; reminders take over. |
Other flags are context rather than blockers: No banking, First collection, Unallocated credit (money already received but not applied — apply it before debiting), Held invoice(s) and Bounced last run / Over mandate max / Unusually large (these three do block).
Standing rules — answers that remember themselves
A review that asks the same question every month is a treadmill, so every answer offers Remember for future runs: the choice becomes the account's standing collection rule, shown on the customer's Billing tab (the Debit-order mandate card) and seeded as an automatic answer on every later run — Collect everything open, Plan only, Capped per run, Always review (forces the account into the queue every run), or Never debit. Accounts without their own rule follow the control room's Default collection rule (Billing → Config → Automation → Billing run): sweep keeps today's propose-everything behaviour; plan only means no account is ever debited beyond its plan without a fresh decision. A rule-seeded answer can always be overridden for one run in the review.
Once the flags are dealt with, click Approve collection. The behaviour depends on the VCR's Debit-order review policy (Billing → Config → Automation → Billing run):
- Safe default (the default) — approving auto-answers anything unanswered as Plan only. No account is ever debited beyond its plan without a recorded answer — a person's or the policy's.
- Strict — approval is refused while any flagged account lacks an answer.
A run with no flagged accounts approves itself at generation, so a clean book keeps flowing unattended. Until a run is approved it cannot be exported or submitted — not by the buttons, and not by the automatic Netcash submitter. Changing any answer re-opens the review (approval is always the last step). Every answer is recorded with who gave it and what they saw.
Autopilot — runs that build themselves
With Debit-order autopilot on (Billing → Config → Automation → Billing run), each collection day's run is generated automatically a few lead days ahead, so the review window is real. A run that needs answers files an Accounts task naming how many accounts are waiting; a clean run approves itself and rides the normal submission sweep. On collection-day morning, a run still awaiting answers is handled by the review policy: safe default answers everything unanswered as plan-only so the batch makes the day's submission; strict leaves it unsubmitted and the stale-run banner flags it. A date whose run was cancelled is never re-created — a cancel is an operator's decision, not a gap to fill. Autopilot is off by default; runs are generated by hand until you switch it on.
When autopilot hits an error, it carries on. Each control room, each collection date and each approval is handled on its own. A problem with one account — say, a subscription whose customer now belongs to another control room — stops only that date's run from being prepared (or only that run's approval). The room's other runs and every other control room's night go ahead. The failed step is rolled back cleanly. The control room gets one Accounts task for the day (Debit-order autopilot: 1 step(s) failed on 15 Sep 2026), due immediately so it lands on Needs attention, listing each failed step with the error.
- A run that couldn't be prepared is tried again on the next nightly pass while its date is still inside the lead window. If it failed on the collection day itself, that was the last automatic try, and the task says so.
- A run that couldn't be approved stays Awaiting review and is tried again each night, but it is never submitted until it is approved.
Fix the cause, or prepare or approve the run by hand. An error that isn't tied to one date or run skips that control room's whole pass for the night, and the task says that too.
The last look before the bank file
Amounts are frozen when an account is answered — but a customer can EFT between approval and submission. Immediately before any bank file is built (export and the Netcash submitter), every pending item is re-checked against its invoice's live balance: a part-paid invoice collects only the remainder, and a settled one drops out entirely. The re-check only ever shrinks amounts, so the approval stands and nobody is ever debited money they no longer owe.
When a customer queries an invoice, open it and use Hold collections (dispute) under its Actions. A held invoice is skipped by every debit-order run and sends no payment reminders until released — but its balance stays on the statement and age analysis. The review shows the held amount on the account so it is never forgotten.
4. Export the bank file
Open the run and click Export bank file. Choose a format:
- Netcash batch file — the South African standard. Only pending items with banking details are included. The file is generated on the server, so your Netcash keys never pass through or get stored in the browser (see Netcash credentials below).
- Generic CSV — a plain, human-readable file for any other processor or manual handling. Needs no credentials.
Both formats debit each customer once per run — a customer's invoices and instalment are one bank line (reference R‹run›C‹customer›), so their bank statement shows one deduction and you pay one transaction fee instead of one per invoice. Reconciliation fans the result back out to every covered invoice automatically (a debit clears or bounces whole). Two guards run at file time: a customer whose total exceeds their DebiCheck authenticated maximum refuses the build by name (cap or split them in the review — the Cap at mandate quick answer does it in one click), and items with differing banking snapshots refuse too (answering the account re-snapshots from the live mandate and heals it).
The file downloads to your device for you to submit to the bank. The run is stamped Exported.
ABSA Online Collections (.trf)
A control room that submits to ABSA Online Collections picks ABSA Online Collections (.trf) as its Bank file under Billing → Config → Automation → Billing run, with its ABSA user code, client name and the statement description debtors see. New runs are then stamped for ABSA, and the runs list grows an Import ABSA batch report button. ABSA takes a whole month as one upload, every debit on its own action date, so a month is generated with New batch… — one run per collection day underneath (a control room's customers may debit on twenty different days), one row and one file on top:
- Approve & build ABSA file (the draft) — every day of the batch becomes one file,
CL‹user code›.trf: a 261-character fixed-width record per customer per day, each line dated its own collection day, arrears folded into the amount. Each run is re-checked against live invoice balances first and stamped Exported. Upload the file on ABSA's portal as before. - Download ABSA file again (the batch window) — rebuilds the same file while no day has been submitted or reconciled yet.
- A single run's Export bank file offers the same format for one collection day.
The record layout is the one control rooms have uploaded from ABSA's own spreadsheet macro for years, so ABSA accepts it unchanged; the first month is still worth comparing line by line against the old spreadsheet's file before it is submitted.
Netcash credentials
Your Netcash keys are stored securely on the server, per VCR — never kept in your browser or pre-filled into the export form. In the export dialog you manage:
- Service Key + Software Vendor Key (required) — used to build the debit-order file.
- Account number + Account Service Key (optional) — enable the automated submission and statement reconciliation described below.
- Pay Now service key (optional) — enables online card / instant-EFT invoice payments for your customers.
Each shows as On file or Not set. Add / Replace sends the values straight to secure storage and clears the inputs immediately; Remove deletes the stored debit-order keys. A Netcash export is disabled until the Service Key + Software Vendor Key are on file, and storing keys requires super-admin mode.
The file is built to Netcash's published NIF batch-file layout, but confirm it end-to-end by uploading a test file to a Netcash test account before your first live run.
5. Reconcile the results
After the bank processes the batch, open the run and click Reconcile. The dialog shows one row per customer (the bank debited them once for all their lines) — mark each customer cleared or returned with a reason; a return re-opens every invoice that debit covered. Already-settled items can still be flipped individually under Late corrections. On Apply:
- Cleared → a
debit_orderpayment is recorded against each invoice, closing it (balance reaches zero → Paid). - Returned → a rejected payment is recorded per invoice. Rejected payments don't count toward the balance, so the invoices re-open for follow-up and the bounce is visible on the Payments tab.
The run moves to Reconciled with cleared / returned totals. If any debits bounced, CleverOps also files an Accounts ticket summarising the failed amount (due immediately, so it lands on Needs attention) — the re-opened invoices are your follow-up list.
Import an ABSA batch report
For ABSA there is no per-customer dialog to fill in: click Import ABSA batch report in the runs list and choose the CSV ABSA gives you — the submission report straight after an upload (every line Accepted, or Failed with a validation warning), and the results report weeks later. Several files of one batch can go in together; they are read in name order and the later line for the same debit wins, so a failed line that ABSA re-submitted as Accepted ends up accepted.
Each line is matched to its run by action date and to the customer by the contract reference (the customer's account number), falling back to the debtor's bank account. Then:
| ABSA says | CleverOps records |
|---|---|
| Successful | cleared — the invoices close |
| Accepted, action date older than the settlement window (Billing → Config → Reminders, default 6 days) | cleared — ABSA reports no return, the money is in |
| Accepted, still inside the window | nothing yet — the item stays pending and the run Partially reconciled until a later report |
| Unpaid / Disputed | returned — the invoices re-open and the bounce policy below runs (a dispute puts the account on Always review) |
| Failed (a validation warning at submission) | returned with that warning; homing branch / account invalid deactivates the mandate like a dead account |
A debit the report carries for a customer who has no item in that run — an instruction still standing at ABSA that CleverOps did not generate — is recorded anyway: the customer's open invoices are paid oldest first, and anything left over becomes unallocated credit on the account. A line whose reference nobody carries is listed as Unmatched for a person; nothing about it is recorded.
Preview runs the whole posting and rolls it back, so the counts shown are exactly what Apply will do; applying records payments and needs super-admin mode, like reconcile. A report uploaded twice records nothing twice: every line is remembered, and re-uploading the same lines simply reports them as already imported.
Tick Historic load for a month that closed in the previous system (the modal ticks it for you when the report's last collection day is over a month old). Only an invoice dated in that month is paid; a debit with no such invoice here is listed as not applied and is not turned into credit or put against other months — it settled an invoice that lives in the old system. The returns are dated on their collection day, so no failed-collection notice goes out for them today.
What a return sets in motion
Every returned debit (late returns included) runs the bounce policy, keyed off the bank's reason:
| Reason looks like | What happens |
|---|---|
| Account closed / frozen / no such account / deceased / sequestration | The mandate is deactivated — nothing re-presents against a dead account — and an Accounts task asks for new banking (or a switch to EFT). |
| In dispute / payment stopped / no authority / mandate cancelled | Nothing auto-retries: the customer's standing rule flips to Always review, so every future run queues them for a human answer, and an Accounts task explains why. |
| Insufficient funds (and anything else) | The invoices simply re-open; the next run's review carries the Bounced last run flag so the retry is a decision, not a reflex. |
And when the Returned-debit fee is set (Billing → Config → Automation → Billing run; ZAR, VAT-inclusive; 0 = off), a bounce drafts one fee invoice per customer per run — an unnumbered draft a person reviews and issues, never an automatic charge, and never a fee on a bounced fee. Mind NCA fee limits for consumer accounts.
Only one live run per collection date can exist at a time — a second Generate for the same date is refused until the first run is reconciled or cancelled, so two people can't accidentally double-collect the same invoices.
While an invoice sits in a live run awaiting the bank's result, automated reminders leave it alone — the customer is never chased for money that is already being collected. When a debit bounces, the customer can get an immediate failed-collection notice with the bank's reason (and a Pay now link when your online gateway is connected); when it clears, the invoice closes and no reminder ever fires. This works identically whether you reconcile manually or via the Netcash integration — both paths flow through the same reconcile step.
Runs needing attention
An amber banner at the top of the Debit orders panel flags runs the state machine can't resolve on its own:
- Never submitted — a run past its collection date still sitting in Generated/Exported (the bank never got the batch).
- No bank results — a Submitted or Partially reconciled run past the settlement window (configurable under Automated reminders, default 6 days) with items still pending.
Click a flagged run to open it, then submit it, pull/capture the bank results, or cancel it. Reminders for the affected invoices stay paused until you do — a stuck batch is an operations problem, so CleverOps flags you, and never auto-emails the customer over it.
Automating with the direct Netcash integration
Once your Netcash connection is configured, CleverOps can talk to Netcash directly — no more downloading a file and keying results back in. These actions only appear once Netcash is connected for your VCR; until then, the manual export and reconcile flow above stays available.
Submit to Netcash
On a Generated or Exported run, Submit to Netcash uploads the batch straight to Netcash, stores the returned file token, and moves the run to Submitted. It appears once your Service Key + Software Vendor Key are on file. A background job also submits due runs automatically, so you can leave it hands-off — but only approved runs are ever picked up; a run awaiting review sits safely until someone answers it. A Same-day / Two-day selector on the run chooses the Netcash service type before the file is built (Two-day is the default).
Pull statement & reconcile
Once submitted, Pull statement & reconcile fetches your Netcash merchant statement for the collection date, matches each paid or unpaid row back to its run item, and reconciles the run — recording cleared and returned payments exactly like the manual reconcile (invoices close or re-open, and bounces file an Accounts ticket). It appears once your Account Service Key is on file, and also runs automatically each morning.
Netcash activity
Below the runs, the Netcash activity panel is a read-only audit of what auto-reconcile pulled from the statement (with the bank's reason codes) and of any Pay Now online payments. It stays hidden until Netcash is connected.
DebiCheck (bank-authenticated mandates)
For dispute-resistant collections, register a customer's mandate with DebiCheck — the account holder approves it at their own bank. In the Banking details dialog (shown when Netcash is connected) switch Collection method to DebiCheck, fill in the account holder's ID number -- with the SA ID / Passport / Other dropdown set to the document it is actually from, because that is what tells the bank whether it is looking at a South African ID -- your DebiCheck template, the instalment amount, first collection date and frequency, then Save and Submit for DebiCheck authentication. The debtor approves at their bank within about two days; the result arrives automatically and flips the mandate to Authenticated (or Rejected). The bank caps any collection at 1.5× the authenticated instalment.
Verify a bank account (AVS)
When your Account Service Key is on file, the Banking details dialog shows Verify account with Netcash (AVS) — a real-time check that the account exists, is open, accepts debits, and matches the account holder's name and ID number, before you ever collect against it.
Pay online (Netcash Pay Now)
With a Pay Now service key on file, your customers can pay their invoices online by card or instant EFT from their account portal — they're taken to Netcash's secure page, and the cleared payment is recorded automatically. The Pay online card only appears in the portal when Pay Now is configured.
A customer with several outstanding invoices settles them in one payment: every unpaid invoice starts ticked, the button shows the combined total (e.g. Pay 3 invoices — R 1 395,00), and they can untick any invoice they'd rather pay later. One Netcash checkout covers the lot; when it clears, CleverOps records a separate payment against each invoice (visible on the Payments tab and in the Netcash activity panel, where a combined transaction shows how many invoices it covered), so statements and invoice balances stay per-invoice accurate.
A Pay Now key pays into one company's Netcash merchant account, so it only ever takes payment for invoices issued by the billing entity it belongs to. The key you store in the export dialog belongs to your default billing entity. Invoices issued by another of your companies are never paid through it: that company's card on the portal's Pay tab has no Pay online button, and a payment attempted any other way is refused with a message naming the company that has no Pay Now key — those customers pay by EFT into that company's own bank account instead. A control room with a single billing entity is unaffected.
Run statuses
| Status | Meaning |
|---|---|
| Generated | Items created — in review (an Awaiting review or Approved pill says which) |
| Exported | A bank file has been downloaded (Netcash, or the month's ABSA file) |
| Submitted | Uploaded to Netcash (direct submit) — awaiting statement reconciliation |
| Reconciled | Bank results applied — payments recorded |
| Partially reconciled | Some items settled; others are still awaiting the bank's result |
| Cancelled | Abandoned before reconciliation; invoices stay open for a future run |
Related
- Standing collections — debit orders a provider runs by itself, imported from its wallet statement.
- Subscriptions — set a subscription to pay by debit order with a collection day.
- Payments — where cleared and returned collections appear; reject/restore individual payments.
- Monthly Billing Run — generates the invoices that debit-order runs collect.
- Automated reminders — how reminders stay silent while collections are in flight, failed-collection notices, and opt-in advance collection notices.