Sum Check Examples

The situation: A supplier sends a nightly file of shipped units along with a delivery note stating the total. Reconciling the loaded rows against that figure catches a truncated transfer or a duplicated block before the stock levels are updated.

Check configuration

Payload

{
    "description": "The delivered units must add up to the 12,480 on the delivery note.",
    "rule": "sum",
    "fields": ["units_shipped"],
    "container_id": 145,
    "filter": "delivery_id = 'D-20260311'",
    "properties": {
        "value": 12480
    },
    "tags": ["reconciliation", "supplier-feed"],
    "additional_metadata": {"jira": "DATA-10500"},
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 12
}

Sample Data (filtered to delivery_id = 'D-20260311')

Why the filter matters

The filter runs before the total is computed, so only the lines belonging to this delivery are added up. Without it, every delivery ever loaded would be summed together and the control total would never match.

What gets flagged

The three loaded lines add up to 10,280 against a delivery note of 12,480: a fourth line of 2,200 units never arrived. No single row is wrong, so the check reports one Shape Anomaly with both totals, and the message ends with the filter that scoped the evaluation.

Flowchart

graph TD
    A["Apply filter: delivery_id = 'D-20260311'"] --> B["Add up units_shipped"]
    B --> C{"Does the total equal 12,480?"}
    C -->|Yes| D["Check passes"]
    C -->|No| E["Shape Anomaly with both totals.<br/>Message ends with<br/>[filter: delivery_id = 'D-20260311']"]

Equivalent SQL

-- The total the check compares against 12,480.
SELECT sum(units_shipped) AS actual_sum
FROM delivery_lines
WHERE delivery_id = 'D-20260311';

The situation: A cost allocation splits every project across departments in whole percentage points. The split must always add up to exactly 100: a total below it leaves cost unassigned, and a total above it double-counts. Whole percentage points make the exact equality safe.

Check configuration

Payload

{
    "description": "The allocation percentages for the project must add up to 100.",
    "rule": "sum",
    "fields": ["allocation_pct"],
    "container_id": 512,
    "filter": "project_id = 'PRJ-8841'",
    "properties": {
        "value": 100
    },
    "tags": ["allocation", "finance"],
    "additional_metadata": {"jira": "DATA-10514"},
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 47
}

Sample Data (filtered to project_id = 'PRJ-8841')

What gets flagged

The three departments account for 95 points, so 5% of the project's cost is unassigned: a fourth allocation row was never created. The values are whole numbers, so the exact equality is dependable here and the gap is unambiguous.

Flowchart

graph TD
    A["Apply filter: project_id = 'PRJ-8841'"] --> B["Add up allocation_pct"]
    B --> C{"Does the total equal 100?"}
    C -->|Yes| D["Check passes"]
    C -->|No| E["Shape Anomaly with both totals.<br/>Message ends with<br/>[filter: project_id = 'PRJ-8841']"]

Equivalent SQL

-- The total the check compares against 100.
SELECT sum(allocation_pct) AS actual_sum
FROM cost_allocations
WHERE project_id = 'PRJ-8841';

The situation: A double-entry ledger stores debits as positive and credits as negative amounts in cents. Every posted batch must net to exactly zero. Storing the amounts in whole cents rather than in currency keeps the total free of rounding, so the exact equality holds.

Check configuration

Payload

{
    "description": "A posted ledger batch must net to zero.",
    "rule": "sum",
    "fields": ["amount_cents"],
    "container_id": 733,
    "filter": "batch_id = 'B-4471' AND status = 'posted'",
    "properties": {
        "value": 0
    },
    "tags": ["accounting", "reconciliation"],
    "additional_metadata": {"jira": "DATA-10529"},
    "template_id": null,
    "status": "Active",
    "owner_id": 7,
    "default_anomaly_assignee_id": 41
}

Sample Data (filtered to posted entries in batch B-4471)

Why the filter matters

The filter keeps unposted entries out of the total. A batch still being written would never net to zero, and evaluating it would report a failure that is simply work in progress.

What gets flagged

The posted entries leave 25,000 cents unbalanced: a credit line of 250 was posted as 150. Because the amounts are whole cents, the gap is exact and points straight at the size of the mistake. No row is individually invalid, so the check reports one Shape Anomaly.

Flowchart

graph TD
    A["Apply filter: posted entries in B-4471"] --> B["Add up amount_cents"]
    B --> C{"Does the total equal 0?"}
    C -->|Yes| D["Check passes"]
    C -->|No| E["Shape Anomaly with both totals.<br/>Message ends with the filter"]

Equivalent SQL

-- The total the check compares against 0.
SELECT sum(amount_cents) AS actual_sum
FROM ledger_entries
WHERE batch_id = 'B-4471'
  AND status = 'posted';