Ask AwraIQ about features, pricing, onboarding, login, integrations, security, demos, mobile apps, automation, reports, or support.
A customer statement takes everything you've invoiced and everything they've paid, lays it out in date order with a running balance, and lands in their inbox as a clean, branded PDF — for whatever period you ask for.
Opening → invoiced → paid → closing · Running-balance ledger · Any date range · Emailed as branded PDF
| Date | Type | Reference | Debit | Credit | Balance |
|---|---|---|---|---|---|
| 01 Jul | Opening | — | — | — | 24,000 |
| 04 Jul | Invoice | INV-2041 | 30,000 | — | 54,000 |
| 12 Jul | Payment | PMT-8817 | — | 20,000 | 34,000 |
| 18 Jul | Invoice | INV-2062 | 38,000 | — | 72,000 |
| 27 Jul | Payment | PMT-8890 | — | 32,000 | 40,000 |
| Closing balance (KES) | 40,000 | ||||
“I already paid that.” “I never got that invoice.” “I thought we agreed a lower figure.” Chasing money is rarely about bad faith — it's about two parties holding different, incomplete pictures of the same account. The moment you can put a single, dated, running-balance ledger in front of a customer, the conversation changes from argument to arithmetic.
That's what a customer statement is for. It's not a new invoice and not a reminder letter — it's the whole story of an account, reconciled to a closing balance both sides can agree on.
Every non-cancelled invoice in the period, on the date it was raised, as a debit that increases the balance.
Every payment received in the period, on the date it landed, as a credit that reduces the balance.
A running balance after each line, and a closing balance that says exactly what's outstanding right now.
Every statement is built the same way, so customers learn to read it once and never question the format again.
Your logo, name, email and phone sit at the top — the statement looks like it came from you, not from software.
Who the statement is for, and the exact window it covers — a From–To range, or “all activity” when you leave the dates open.
Opening balance, total invoiced, total paid and closing balance — the headline numbers before anyone reads a single line.
Date, type, reference, description, debit, credit and balance — every invoice and payment in date order, each with the balance after it.
The final running balance: the single figure that says what this customer owes as of the end of the period.
Opening balance is carried from the customer's own account balance, so the statement doesn't pretend the relationship started on day one of the period. Every invoice raised (excluding anything cancelled) is a debit; every payment received is a credit; and the balance column simply carries the arithmetic forward line by line.
Because it is generated from your live invoices and payments — not typed up by hand — the numbers on the statement are the same numbers in your system. There is no re-keying, and nothing to fall out of sync.
Open a customer and hit Send Statement. Choose a From and To date, or leave them open to cover everything to date.
Invoices and payments in that window are pulled, sorted by date, and accumulated into a running balance automatically.
The ledger is laid out on a branded A4 Statement of Account and saved securely against the customer.
The PDF is queued and sent as an attachment, to the recipients you chose — no printing, no manual send.
A statement is a customer touchpoint, so you decide exactly how it lands — who receives it, what it says, and the period it covers — from a single dialog.
Entries are sorted by date and the balance accumulates line by line — opening plus debits minus credits — so the closing figure is provably correct.
Set a From–To window for a monthly or quarterly statement, or leave it open to show the customer's entire history to date.
The PDF carries your logo and contact details in the header, so it reads as an official document from your organisation.
The statement currency follows the customer or your base currency, and each line carries its own currency label for clarity.
Cancelled invoices are excluded automatically, so a statement never shows a charge that was voided.
Only users with customer access can send statements, and every statement is strictly scoped to your own organisation's data.
Trigger a statement from the customer screen, or via a token-authenticated API with idempotency for safe, repeatable sends.
Each generated statement PDF is stored against the customer, so there's always a record of exactly what was sent.
No activity in the period? The statement says so plainly instead of sending a confusing blank page.
A statement is only as trustworthy as the data underneath it. Because AWRA builds each one directly from your live customer invoices and payments at the moment you send it, there is no export-then-edit step where numbers can be massaged or go stale.
Raise an invoice, record a payment, void a charge — and the very next statement reflects it. The customer's running balance and your receivables are the same source of truth, presented for the customer to read.
A customer statement is a running-balance ledger of invoices and payments, delivered by email as a branded PDF. It is deliberately focused: it summarises what was billed and paid over a period and the balance that remains. It is not an aging report with 30/60/90 buckets, it doesn't break out tax lines, and it labels currency rather than converting it. For dunning workflows and overdue analysis, statements pair with Aging Reports and Payments & Collections — each doing the job it does best.
The invoices and payments it summarises live across the sales and receivables suite. Follow the thread:
Pick the customer, pick the period, and let AWRA build and email the running-balance statement — reconciled to a closing balance you both can trust.