Statements

Getting bank statements into Billing Booster and applying the payments they contain back to your WHMCS invoices — the day-to-day side of statement processing.

The Statements tab is where you import statement files and apply the payments they carry. Applied payments are then listed on the Transactions tab.

Set it up first

The Statements tab only appears once Statement Processing is included in your license and you have an enabled statement configuration. See Configuration → Statement Processing to set it up, optionally with a bank connection — and make sure the Payment Code gateway is installed, or applying a payment will fail.

One subtab per configuration

With more than one enabled statement configuration, the tab shows a subtab for each, named after it, in the order set under Settings → Statement Processing. Everything on a subtab belongs to that configuration: its settings, its bank connection, and its own archive of files. The subtab you used last is shown again next time.

With a single configuration, there is no subtab bar.

Getting a statement

• Upload Statements — upload one or more files in the configuration's format (.xml for camt.054 and camt.053, .csv for CSV), or a ZIP archive containing them. This works with any bank that exports the format. A camt file in the other camt format is refused — "… is a camt.053 file; upload it on the tab of a camt.053 configuration" — so that every file is processed with the settings meant for it.
• Download from Bank — pull the latest statements through the configuration's bank connection (MFTPF, EBICS, Revolut Business or Enable Banking). Only available once a bank connection is configured and ready. Until then, the card says what is missing: a connection, a finished EBICS setup, or — for Revolut Business and Enable Banking — an authorisation the bank still accepts. It also warns two weeks before an authorisation runs out.

Either way, Billing Booster reads the statements and opens the transaction preview. Anything that needs your attention but didn't stop the import — a refused file, or bookings without payment details — is shown as a warning.

Reviewing and applying

The Preview Transactions dialog lists every incoming payment the statements contain, each matched (where possible) to an invoice and client, with the invoice's status and balance, the amount paid, the booking date, the payer, and how the payment relates to the balance (Full, Partial, Excess).

1. Review the proposed matches and select which payments to apply. Payments on unpaid invoices are preselected. A payment that can't be applied has no checkbox: its invoice wasn't found, or it has already been recorded (Exists).
2. Payments matched by the invoice number in their note, rather than by their reference, are marked From note — hover over the mark to see the note. They are not preselected: tick them once you have checked them. (With Match by invoice number in the payment note set to Off, there are none.)
3. Details on a row shows everything about the payment: as the bank reported it (amount, booking date, payer and their account, structured reference, bank reference, how it was matched), the client, the invoice with its total, what has been paid so far and its balance, and the payments already booked on it.
4. Click Apply n Payments — Billing Booster records the selected payments against their invoices in WHMCS. The result lists what was applied, with its transaction ID, and any errors it hit. Print prints it for your records.

A payment on an invoice that is already paid

A client who pays an invoice twice — once by card, once by bank transfer, say — leaves a payment whose invoice is already Paid. The preview marks it Already paid, and does not preselect it. Tick it to book it anyway: a warning above the list says how many such payments are selected. The payment is recorded on that invoice, and since there is nothing left to pay, WHMCS credits the amount to the client.

Automatic processing never books such a payment by itself: it puts it on the review list.

Archived files

Processed files move to the configuration's Archived Files list and are retained for the number of days set under Shared settings, whether they were uploaded or downloaded. Each archived file has two buttons: Process re-runs it and opens the preview again, and Download fetches the original file.

Each configuration archives into its own folder below the Data Storage path, named after its type and ID — for example camt054-1/ or camt053-4/.

Payments to review

Automatic processing applies what is unambiguous: a payment matched to an unpaid invoice. Anything else it leaves alone — and rather than skip it without a word, it puts it on a review list on the Overview tab.

Mark	Why it wasn't applied
Already paid	The invoice is already paid — the client may have paid twice.
Not payable	The invoice is in a status that takes no payment, e.g. cancelled or refunded.
Invoice not found	The payment's reference names an invoice that doesn't exist.
Match from note	The invoice was found in the payment note, and the configuration leaves such matches for an admin to confirm.
Overpaid	It was applied, but paid more than the invoice's balance. Listed so you notice the surplus.
Failed	Applying it failed; the entry says why.

Each entry shows the amount, the invoice, the client or payer, the booking date and the configuration it came from, with three buttons: Details (as in the preview), Dismiss to take it off the list, and — for Match from note, Failed and Already paid — Apply (Apply anyway for a paid invoice) to book it from here. The list only appears while there is something on it.

Unless you turn it off under Shared settings, the admins also get one email per run listing the payments that were added to the list.

Automatic processing

Billing Booster can run the whole pipeline unattended — download new statements through the bank connections, match the transactions, apply the payments. It works through every enabled configuration that has a bank connection and Enable automatic sync switched on, in the order set under Settings. A configuration without a bank connection has nothing to download, so it is never synced.

Automatic processing applies payments matched by their reference to an unpaid invoice. Payments matched by the invoice number in their note are only applied if the configuration's Match by invoice number in the payment note is set to Automatic. Everything it doesn't apply goes to the review list. One configuration failing doesn't stop the ones after it.

When it runs is one switch for all configurations: Sync in the WHMCS daily cron, under Shared settings.

Sync in the WHMCS daily cron	When the sync runs
On (default)	Once a day, immediately before the WHMCS daily automation run.
Off	Only when you run crons/billboost.php from the system cron — on whatever schedule you choose.

Either way, it is harmless when unused: the run exits immediately unless Statement Processing is licensed and a configuration is set up for automatic sync. Every exit is written to the Logs tab with the reason, so a run that decided to do nothing never looks the same as a run that never happened.

Once a day, with the WHMCS cron

With Sync in the WHMCS daily cron on, there is nothing else to schedule — if crons/cron.php runs, so does this. The run happens just before WHMCS' daily automation, so its time of day is the one set under Setup → Automation Settings → Automation Task Time, not the frequency your system cron fires cron.php at.

For this to work, the WHMCS system cron must be running on the server.

On your own schedule

Once a day is too coarse if your bank publishes statements several times a day. For that, Billing Booster ships a standalone cron script you can schedule as often as you like.

1. Turn Sync in the WHMCS daily cron off under Shared settings. That is what hands the sync over — while it is on, the script refuses to run, and logs why.
2. Add a system cron entry pointing at crons/billboost.php inside your WHMCS installation. Every 30 minutes, for example:

0,30 * * * * php -q /home/example/public_html/crons/billboost.php >/dev/null 2>&1

Adjust the path to match your installation, and the schedule to match how often your bank publishes. The script uses the same PHP CLI binary and the same WHMCS installation as crons/cron.php, so if you already have a working WHMCS cron entry, copy its php path.

If your crons directory lives outside the web root

crons/billboost.php finds WHMCS the same way crons/cron.php does: it reads crons/config.php and honours the $whmcspath variable set there. An installation that already has that file working for the WHMCS cron needs no further setup.

<?php
$whmcspath = '/home/example/whmcs/';

In the rare case where the modules/ tree hangs off a different root than init.php does, set $whmcsbtpath alongside it.

Check that it ran

Each run writes a Cron (script): statement processing started line to the Logs tab, followed by what it did or why it stopped. Runs from the daily WHMCS cron are logged as Cron: instead, so the two are easy to tell apart.

The daily cleanup

Billing Booster also runs a cleanup on the WHMCS daily cron. It deletes activity-log entries older than the retention period set under Settings → Logging, and archived statement files older than Retain processed files in the shared settings — whether or not their configuration has a bank connection.

Match failures

If a payment doesn't match an invoice, the most common cause is a payment without a structured reference. Swiss QR-bills always carry one; for SEPA payments, turn on Use an RF creditor reference on the EPC payment code. For payments that still arrive without one, see How payments are matched, and check the Logs tab for details.