3.3Running totals
The essentials in 30 seconds
- Summary = final total, running total = rising total: the summary (2-2) gives ONE total at the end; the running total shows the intermediate total on each row (running balance, total to date).
- The crucial setting is the Reset: never (global running total across the report), per group (restarts from zero per customer/account), or on formula — it gives the running total its meaning.
- A running total depends on order: it adds up in display order — sort the rows first (by date for a statement), otherwise the intermediate balances are meaningless.
Running mini-case — Farès produces the running statement per customer
Farès, management controller in Algiers, must provide each sales rep with the statement of their customers showing the balance AFTER each invoice — not just the final total. He creates a running total field (explorer → Running Total Fields): Amount field as Sum, evaluated for each record, reset on change of Customer group, rows sorted by date. Each row now shows the cumulative balance at that date, restarting from zero for each customer. Sales reps follow the trend instead of discovering the total at the end.
This same case returns in the lesson, the diagram, the script and the 48h challenge.
1. Running total vs summary: the rising total
A need that classic summaries do not cover: the RUNNING TOTAL — a sum (or count) that ACCUMULATES row after row, showing the total “at this row”. Examples: running balance of an account statement (each row shows the balance after the transaction), total “to date”, ranking accumulation. Where a summary gives ONE total at the end of a group or report, the running total gives the INTERMEDIATE total on EACH row, growing as it goes.
Crystal Reports provides a dedicated tool: running total fields, created in the explorer. You define three things there: (1) the FIELD to accumulate and the OPERATION (Sum, Count…); (2) the EVALUATION condition (for each record, or on condition — only add certain rows); (3) above all the RESET condition — when to set the running total back to zero. The running total displays in the Details section (the total on each row) or in a footer (the final accumulation).
2. The reset: the setting that does everything
Three Reset choices, three different meanings. Never reset: the running total runs across the WHOLE report, from start to end — a global total rising continuously (running overall balance). Reset on change of GROUP: the running total restarts from zero for each group — a running balance PER customer, PER account (Farès's case). Reset on a FORMULA: custom condition for special cases. Setting the reset correctly is the difference between a correct running total and an inconsistent total.
Two cautions. First the ORDER of rows: a running total adds up in display order — unsorted rows (by date for a statement) produce absurd intermediate balances while the final total looks fine. Then join duplicates (level 0): as with summaries, multiplied rows inflate the running total — as do unsuitable evaluation conditions (adding too many or too few rows). If inconsistent: check order, then Reset, then the evaluation condition, in that order.
🔎 Concrete example — Running balance per customer, full settings
Farès sets up his running total field for sales statements.
Field: {Factures.Montant} — Sum operation
Evaluate: for each record
Reset: on change of group (Customer)
→ rows sorted by date; running total placed in Details.Reading: each row shows the balance at that date, per customer.
Lesson: the same running total on “never” would give an overall balance — different need, different Reset.
Section vocabulary
- Running total
- Sum or count accumulating row after row, showing the total “at this row” (running balance, total to date).
Simple example: The balance after each invoice in Farès's statement.
What it is not: a summary giving only a final total.
Reflex: as soon as you need to see the progression, not just the end.
- Running Total Field
- Dedicated object created in the explorer: field to accumulate, operation (Sum, Count…), evaluation condition and reset.
Simple example: Farès's Sum field on {Factures.Montant}.
What it is not: a counter hand-coded in a formula.
Reflex: use the dedicated tool rather than DIY.
- Reset
- Crucial setting: when to set the running total back to zero — never (global), on each change of group (per customer/account), or on formula.
Simple example: The per-customer restart in Farès's statements.
What it is not: a running total that keeps rising from one customer to the next.
Reflex: choose the Reset from intent first.
- Running total vs summary
- The SUMMARY (2-2) gives a total at the end of a group/report; the RUNNING TOTAL gives the intermediate total on each row, growing.
Simple example: Customer final total vs balance after each invoice.
What it is not: a summary copied into Details as a running total.
Reflex: progression → running total; synthesis → summary.
- Order dependency
- A running total adds up in display order: badly sorted rows give wrong intermediates (even if the final is right).
Simple example: The statement sorted by date before any accumulation.
What it is not: a running total on rows in the database's random order.
Reflex: always sort before accumulating.
In practice — Create a running total
- Create a running total field (explorer → Running Total Fields → New): field to accumulate + Sum operation.
- Set the RESET per the need: never (overall balance) or on each change of GROUP (balance per customer/account).
- Place the running total in the Details section and SORT rows in the expected order (date, sequence).
- Check in preview: the total grows row after row and resets (or not) as expected.
Ready-to-say script — hand over the statements to sales reps (30 s)
“Each statement now shows the balance after each invoice, in date order, and restarts from zero for each customer. You follow the trend instead of discovering the total at the end — and the running total recalculates itself on every refresh.”
Say when handing over the statements; show one row and its running balance.
Copy-paste template — manual running total in a formula (Crystal syntax)
// @RunningTotal formula placed in Details (if needed outside the dedicated tool)
WhilePrintingRecords;
NumberVar RunningTotal;
RunningTotal := RunningTotal + {Factures.Montant};
RunningTotal
// @ResetRunningTotal formula placed in Customer Group Header
WhilePrintingRecords;
NumberVar RunningTotal := 0;Freelancer
A well-reset running total field and your running statements sell themselves.
SME in Algiers
Farès delivers per-customer statements: balance on each row, sorted by date.
Project team
Standardize the per-Customer-group Reset for all sales statements.
Beginner
This week: one global running total (never) + one per-group running total, compared in preview.
✓ Best practices
- Choose the Reset BEFORE creating the running total: it defines what the figure means.
- Always sort rows in the expected order before accumulating (date, sequence).
- If inconsistent, check in order: sort, Reset, evaluation condition.
✗ Common pitfalls
- Forgetting the sort: absurd intermediates with a final total that looks fine.
- Leaving “never reset” for a per-customer need (or the reverse).
- Accumulating on rows duplicated by a bad join (inflated sums).
Key takeaways
- The RUNNING TOTAL shows the INTERMEDIATE total on EACH row (running balance) — the summary only gives a final total.
- Dedicated tool: RUNNING TOTAL FIELDS — field, operation, evaluation condition and above all RESET.
- RESET: NEVER (global), PER GROUP (restarts per customer/account), or ON FORMULA — it determines the running total's meaning.
- A running total DEPENDS ON ORDER: sort first, check in preview, watch join duplicates.
48h challenge — apply tomorrow
Produce 1 real running statement (per-group running total, sorted rows) and have it checked by a sales rep row by row.
- I distinguish running totals from final totals.
- My Reset matches the intent (global or per group).
- My rows are sorted and my running total checked in preview.
Frequently asked questions
Running total or summary: when to use which, and how to set the reset?
The SUMMARY (2-2) gives ONE total at the end of a group (subtotal) or report (grand total) — use it for a group or overall total. The RUNNING TOTAL gives the PROGRESSIVE total on each row — use it for a ROW-BY-ROW BALANCE (statement), a total “to date”, an accumulation restarting per category. Running total prerequisites: grouped report if per-group Reset, sorted rows. Settings: “never reset” = continuous global accumulation; “on change of group” = restarts from zero per group (balance PER customer); “on formula” = custom condition. The “group the rest / Others” option and conditional accumulation (only adding certain rows) complete the tool.
My running total gives inconsistent results: which causes should I check?
In order: (1) ROW ORDER (cause #1) — the running total adds up in display order; without sorting by date/sequence, intermediates are meaningless while the final can be right. Fix: SORT first. (2) Badly set RESET — a “never” that keeps rising from one customer to the next, or a reset on the wrong group. Fix: set per intent. (3) The EVALUATION CONDITION — “for each record” by default; if you only want to accumulate certain rows, the condition must match. (4) JOIN DUPLICATES — multiplied rows = inflated running total, as with summaries. Check a running total against known values row by row, not just the final total.
What does a running total's reset control?