Mortgage broker IDR reporting: reconcile the reporting population

Delegate IDR reporting preparation by asking support staff to reconcile source records to an approved complaint population, then trace every included case into the coded export. Keep inclusion, classification, closure and submission decisions with the licensee's nominated owner. For a data-file submission, finish the reporting task only when the actual file has passed both ASIC validation stages.

This workflow is for a mortgage brokerage operating under its own Australian credit licence. ASIC's reporting FAQs confirm that all Australian credit licensees are in scope and the reporting obligation belongs to the licensee. A credit representative supplies information through their licensee's process; being a representative does not itself create a separate licensee submission.

Set the reporting boundary before extracting records

Name the entity, reporting period, cutoff date, preparer, decision owner and authorised submitter. Record which approved systems and representative records are included in the extraction. Have the owner identify gaps in that coverage before anyone labels the population complete.

ASIC's reporting page sets six-month periods ending 30 June and 31 December, with submission windows ending 31 August and the last day of February respectively. The December 2025 handbook was first used for the July–August 2026 submission window. Use the current handbook and template for the period being prepared.

In REP 840, published on 13 October 2026, ASIC identified underreporting from credit representatives to licensees and from licensees to ASIC. Its findings included unclear guidance about quickly resolved complaints. This makes the path from source records to the reporting population worth checking, rather than trusting a final spreadsheet total.

Reconcile six source entries into four reportable cases

Everything below is fictional. The exercise covers 1 January–30 June 2026 and assumes each complaint was first received after the firm's initial reporting period began. The dates described as closed have already been assessed by the designated complaints owner under the current reporting rules.

ASIC's scope and reopening FAQs require cutoff reporting for complaints required to be covered, or covered, by the firm's IDR procedure: include those received during the period or open at any point in it. A July closure cannot turn a complaint that was open on 30 June into a closed June-period record.

Fictional source-to-population reconciliation

Source and case	Recorded history	Owner-approved treatment for January–June
S01 → C201	Received 18 December 2025; open at January start; closed 16 January 2026	Include once, closed
S02 → C202	Received 3 March 2026; closed 4 March	Include once, closed; quick resolution does not remove it
S03 → C203	Received 29 June 2026; open at cutoff; closed 8 July	Include once, open at 30 June
S04 → C204	Received 7 October 2025; closed 21 October; never reopened	Exclude: closed throughout this reporting period
S05 → C205	Received 10 November 2025; closed 24 November; reopened 12 May 2026; still open at cutoff	Include once, open, using the existing case ID
S06 → possible C203 follow-up	A second record contains a 30 June follow-up about the same matter	Hold for owner review; in this exercise the owner confirms it belongs to C203

The approved reconciliation is six source entries, five distinct cases, one excluded case and four included cases: two open and two closed. S06 remains linked to C203 as supporting history; it does not become a fifth export row. Record who approved that relationship and why. Until they decide, describe it as a possible duplicate, not a resolved discrepancy.

Keep an exclusion row for C204 and a linkage row for S06 so another reviewer can reproduce the total. Check both directions: every source entry has a disposition, and every export row has an approved case. An unexplained difference of zero is still unexplained if the underlying cases are wrong.

Show how the approved population becomes coded rows

The IDR data reporting handbook requires one row per complaint per period and the same unique identifier when a complaint is reported again. Table 6 uses status 1 for open and 2 for closed; an open complaint's date-closed field stays blank.

The following is a selected-field export excerpt, not a complete upload template. Its headings follow the handbook. Complete all other required fields using the current ASIC template, dictionary and owner-approved coding. Do not insert explanatory words such as “blank” into empty CSV cells.

Fictional coded export excerpt after population approval

ComplaintUniqueID	ComplaintStatus	DateReceived	DateClosed
C201	2	18/12/2025	16/01/2026
C202	2	03/03/2026	04/03/2026
C203	1	29/06/2026
C205	1	10/11/2025

For each remaining coded field, retain the source location, proposed value, dictionary reference and owner's approval or question. Route uncertain product, issue and outcome classifications back to that owner. Do not select whichever code makes the file pass, infer closure from a completed CRM task, or carry an old outcome into an open case without checking the field's requirements.

Give the full export a version identifier and compare its four unique IDs with the approved list. Recheck totals after sorting, filtering or conversion to CSV. Keep the cutoff snapshot separate from the current register: C203's July closure belongs in the ongoing case history without silently changing the June snapshot. The document version-control guide helps preserve the exact reviewed copy.

Hand over the file and collect both validation results

ASIC's validation FAQs say a data-file submission succeeds only after both basic and deep validation pass. Deep validation can take up to 48 hours. Allow time for correction and resubmission before the window closes.

Keep declaration and submission with the authorised person. The preparer's handoff should identify the entity, period, approved case list, full export version, four-row count, approvals and any remaining issue. Under this proposed workflow, unresolved population or coding questions return to the owner before release.

Evidence to retain for a real submission

Checkpoint	Record against the exact export
Basic validation	Actual on-screen result or upload-confirmation email, transaction reference and time
Deep validation	Actual result email and matching portal transaction status; retain any failure attachment
Final reconciliation	Owner-approved export version and case count linked to the successful transaction, including any replacement history

The handbook's submission appendix distinguishes Submitted while deep validation is pending, Failed after a deep-validation failure and Completed after success. A local spreadsheet check supplies none of these receipts. This fictional exercise has no ASIC transaction or validation result; never upload the example as a real report.

Return errors to their source before closing the task

If a real validation error points to C203's closure date, trace it through the export version to S03 and the approved cutoff decision. Have the owner confirm the correction, regenerate the full approved file and repeat the row reconciliation. Retain the failed version and error beside its replacement. Do not mark the task complete while a deep result is pending or failed.

When hiring, specify source reconciliation, controlled coding preparation and receipt tracking, with a named decision owner. The separate complaint-intake guide covers recognising and handing over new concerns. Discuss the reporting-preparation support your brokerage needs, including systems, review responsibilities and submission boundaries.