Reports & formats

Once a request is ready, its report is available. Every report is built from the transactions in the accounts the customer chose to share, reconciled against their banking data, and carries a verification ID and method note.

Report types

• Expense summary (expense_summary) — verified income, categorised expenses, and the customer’s monthly position (income, expenses, surplus). Built for hardship and debt-management assessments.
• Affordability (affordability) — a per-account view with income verification and risk indicators (for example small-amount credit contracts), aimed at responsible-lending and broking use.

Reports cover the most recent 3 months of transactions in the shared accounts — the period the customer consents to at their bank, and the window the engine analyses even if a bank returns more.

Fetch the report

Returns the structured report as JSON:

curl https://api.statementiq.com.au/v1/requests/req_1a2b3c/report \
  -H "X-API-Key: siq_test_your_key"

The JSON includes the client block (name, verification ID, generated date), the position summary, categorised transactions, and a compliance disclaimer. A ready-to-share HTML version is available at:

Transaction categorisation

Every transaction in the report carries two labels, plus a third when the request has a budget template set:

• category — StatementIQ’s classification, from a model trained on Australian bank-statement descriptions and tuned for hardship and affordability work (wages, Centrelink, loan repayments, BNPL, gambling, dishonours, and so on). This is what the report’s summaries, streams and totals are built from.
• fiskil_category — the CDR feed’s own enrichment label (Fiskil’s primary_category, e.g. GROCERIES), passed through untouched. It’s empty when the bank or Fiskil didn’t supply one. Use it to reconcile against the bank’s view, or to drive your own rules where a general-purpose merchant category is more useful than an affordability one.
• budget_line — only when the request has a budget_template (see Budget summary below): the line the transaction lands on in that fortnightly household budget. Anything the banking data can’t honestly place — a loan repayment we can’t tell is secured, a transfer to an account that wasn’t shared, cash out, gambling — carries a needs allocation line instead of a guess.

{
  "date": "05/03/2026",
  "description": "WOOLWORTHS 1234 SYDNEY",
  "amount": -150.00,
  "balance": 2250.00,
  "category": "Groceries",
  "fiskil_category": "GROCERIES",
  "budget_line": "Food" // only with a budget_template
}

Where our model is unsure, it uses the Fiskil label as a tie-breaker when grouping expenses — so the two usually agree, but category is the one the figures in the report follow.

For a debit, StatementIQ’s model comes first for the two classes an assessor must always see — gambling, and dishonours and fees — so that neither a merchant name in the narration nor the word ATM can mask them (a casino ATM withdrawal is gambling, an ATM fee is a fee). Then cash out, because an ATM withdrawal at a supermarket is a withdrawal and not groceries. Then a curated Australian merchant rule (telcos, energy and water retailers, fuel, supermarkets, health funds, insurers, pharmacies, childcare, schools, rental-goods lenders, fines), then the model’s remaining confident classes (loans, BNPL, rent), then transfers to Transfers (external), then the bank’s label. Thebudget_linefollows the same order, so the category on screen and the line on the form never disagree about where the money went. Movements between the customer’s own shared accounts are Transfers (internal)and excluded from income and expenses. Send us a mis-categorised merchant and it’s a one-line rule.

Budget summary (optional)

Firms that assess against a set household-budget form can switch on a budget template (Portal → Settings → Budget template, or budget_template on the request). The expense summary then carries a budgetblock — the customer’s income and expenses summed onto the form’s lines, fortnightly — ahead of the category breakdown in the PDF, and every transaction carries itsbudget_line. Without a template neither field is present. Currently available: afsa_part_ix, the AFSA Part IX debt-agreement lines. Fortnightly figures are period totals divided by the fortnights in the period;unallocated lists what an assessor still needs to place, andsurplus is struck before those items —unallocated_total is reported alongside it. A credit from a lender (a payday advance, another loan drawdown, BNPL credit) is a borrowing, not earnings, so it is listed for review under needs allocation rather than counted as household income.

"budget": {
  "template": "afsa_part_ix", "basis": "fortnightly", "fortnights": 6.5,
  "income":   [{ "line": "Income from Employment (After Tax)", "fortnightly": 1857.64, "period_total": 12074.66, "count": 7 }, ...],
  "income_total": 1857.64,
  "expenses": [{ "line": "Rent", "fortnightly": 490.00, "period_total": 3185.00, "count": 7 }, ...],
  "expenses_total": 1233.85,
  "secured_creditor_payments": { "line": "Secured Creditor Payments", "fortnightly": 0, ... },
  "surplus": 623.79,
  "unallocated": [{ "line": "Loan & credit repayments (allocate: secured, or creditor not receiving dividend)", "fortnightly": 120.00, "count": 6 }],
  "unallocated_total": 120.00
}

PDF, CSV and XML

From the portal you can download each report as PDF, CSV, HTML or XML, and an expense summary also as an Extended PDF. The standard PDF carries the budget (when the request has a template), the expense groups, each category with its recurring streams, and the full ledger. ?detail=extendedlists every transaction under its category as well — but only on an expense summary. An affordability report already nests every transaction under its stream, so the parameter is accepted there but changes nothing, and the portal only shows the Extended PDF button on expense summaries. The CSV is the ledger — one row per transaction with category, budget line and the bank’s label — for either report type.

Breakdowns — one analysis, several documents

Lenders often want the same data split into separate documents. Choose which in Portal → Settings → Report breakdowns, or per request with report_breakdowns:

• summary — one combined report covering every connected account.
• by_bank — one report per institution.
• by_bank_account — one report per individual account.

List what a request produced:

{
  "reports": [
    { "breakdown": "summary",         "scope": null,             "label": "Summary" },
    { "breakdown": "by_bank",         "scope": "ING",            "label": "ING" },
    { "breakdown": "by_bank_account", "scope": "ING/····6789",   "label": "ING ····6789" }
  ]
}

Every report endpoint accepts ?breakdown= and ?scope= to select one of them. Omit both and you get the summary — so existing integrations are unaffected.

curl "https://api.statementiq.com.au/v1/requests/req_1a2b3c/report.pdf?breakdown=by_bank&scope=ING" \
  -H "X-API-Key: siq_live_your_key" -o ing.pdf

Or take everything in one archive — one file per report per format:

Defaults to HTML and XML; add ?formats=pdf,html,xml,csv to include PDFs and the CSV ledger. In the portal the same archive is the “Download all” button, and report email delivery attaches it when a request produced more than one document.

Using reports responsibly

A report is an information tool, not financial product advice, credit assistance, or an audit. Automated categorisation is not error-free — material items should be reviewed, and a report should not be the sole basis for a decision. Each report carries its own method note and disclaimer. See our Terms of Service.