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 StatementIQ’s category, the data provider’s labels and merchant, and a budget line 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. In an affordability report, category is the model’s own label (Wages, Centrelink, Loans, SACC Loans, BNPL, Gambling, Dishonours, Fees, Rent, …). Where the model doesn’t place a transaction, it carries the spending category an expense summary gives it (Groceries, Dining & entertainment, Transfers (internal), …), or Uncategorised when neither can place it. Income, affordability and the risk indicators come from the model’s labels only, so the spending categories don’t change them.
• fiskil_category and fiskil_subcategory — the CDR feed’s own enrichment labels (Fiskil’s primary_category and secondary_category, e.g. RENT_AND_UTILITIES / RENT_AND_UTILITIES_TELEPHONE), passed through untouched. Empty when the bank or Fiskil didn’t supply one. Use them 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.
• fiskil_confidence, merchant_name and merchant_category_code — how sure Fiskil was of its category (VERY_HIGH, HIGH, MEDIUM or LOW; we don’t act on a LOW label), the merchant the bank identified, and the card network’s merchant category code (MCC). Each is an empty string when it wasn’t supplied — a payment to a person never has a merchant.
• 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": "FOOD_AND_DRINK",
  "fiskil_subcategory": "FOOD_AND_DRINK_GROCERIES",
  "fiskil_confidence": "VERY_HIGH",
  "merchant_name": "Woolworths",
  "merchant_category_code": "5411",
  "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 payments to a person or another account: these are Transfers (external)whatever their payment reference says — a reference is free text the payer typed, so “payback for food” or “rent” to a family member is left for the assessor to allocate rather than filed as food or rent. We recognise them from the bank’s transaction type and wording (“Transfer To”, PayID, Osko, “Pay Anyone”, “Mobile Banking Payment”…) and, where the bank identifies merchants on the account, from a payment that has no merchant at all. Only a payee that identifies itself survives a transfer: a lender we know by name, or a letting agent (rent). The one memo we do act on is rent that repeats: a reference naming rent, to the same payee, at least twice, each within 10% of the same amount, on a weekly, fortnightly or monthly cycle is Rent & housingon the Rent line. A one-off “rent” or irregular amounts stay with the assessor. 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 loan and BNPL classes, then Fiskil’s secondary category (its primary is too broad: RENT_AND_UTILITIESis rent, power, water, phone and internet together, so on its own it is never read as rent), then the model’s rent class, then Fiskil’s primary category. The budget_linefollows the same order, so the category on screen and the line on the form never disagree about where the money went. Send us a mis-categorised merchant and it’s a one-line rule.

Movements between the customer’s own shared accounts are Transfers (internal) and excluded from income and expenses (internal: true). Two exceptions keep debts visible. A payment into the customer’s own loan or mortgage account is a loan repayment — counted as a debt commitment, and on the budget a repayment into a mortgage is a secured creditor payment. Everything recorded insidea loan account (instalments received, interest and fees charged) is the lender’s ledger, shown as Loan account activityand not counted — so a loan’s interest is not counted again on top of the repayment that pays it. Credit cards are unchanged: card purchases are the spending, and paying the card off is an internal transfer. Rows that aren’t counted carry a budget_linethat says so (“Not counted (transfer between own accounts)”, “Not counted (entry inside a loan account)”).

The monthly positioncounts known spending only. Transfers to people or to accounts that weren’t shared, and cash out, are money leaving but not known expenses (and money coming back the same way isn’t counted as income), so they are reported beside expenses as position.monthly_transfers_out (and expenses.transfers_out_total) for the assessor to allocate — the same split the budget makes. The Transfers & withdrawals group still appears in expenses.groups.

Accounts and data completeness

Each account is identified by its institution, nickname, full account number and BSB as the bank returned them (client.accounts, accounts_detail and reconciliation carry account_number and bsb), so you can confirm every account the customer shared is present.

A report is built only when every consented account has delivered its transactions. If a bank never sends one, the report says so in data_gaps — and on page one of the PDF — instead of showing that account as empty:

"data_gaps": [
  { "institution": "CommBank", "account_number": "34484337", "nickname": "fix car",
    "reason": "No transactions were received from the bank for this account, so it may be missing activity." }
]

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 — whether our model knows the lender by name or the data provider tags the credit as a cash advance or loan.

Income lines: wages and Centrelink our model recognises go on Income from Employment (After Tax) and Government Support (or Taxable Centrelink Income). Any other credit that isn’t a transfer is placed by the data provider’s detailed category — salary, self-employment, government benefits, child support or investment income each go on their own line. Other Incomeis the form’s catch-all for income with no line of its own: tax refunds, rental income, and credits nobody could place. A transfer in from a person or an unshared account is listed for review, not counted as 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 account number, BSB, category, budget line and the bank’s label — for either report type.

Transactions by account (?detail=accounts, the “By account PDF” in the portal) is a separate document alongside the consolidated one: each account on its own page with its opening and closing balance, credits, debits and full ledger. In every PDF, credits and debits are unmistakable — the ledgers have separate Debit and Credit columns, and the Extended PDF shows each amount as +$ (in green) or -$ with the running balance beside it.

Report email delivery (Portal → Settings → Report delivery) can attach any of these: the PDF, the Extended PDF, the By account PDF, HTML, XML and the CSV ledger — so a submission arrives complete without a trip to the portal.

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.