Anonymised, illustrative composite. A contractor building its annual T5018 list found one active subcontractor missing entirely — not because the sub had gone unpaid, but because every one of its invoices had been coded to the wrong account.
At a glance
A general contractor worked with 26 active subcontractor accounts over the course of the year, building its T5018 information return the way most contractors do: pulling every payment coded to a Subcontract Labour general ledger account and aggregating the totals by vendor for the year.
Income Tax Regulation 238(2) requires an information return from every person who pays an amount for goods or services rendered in the course of construction activities, where the payer’s business income for the period is derived primarily from those activities — which describes this GC and every one of its genuine subcontractors. A roofing subcontractor had invoiced the firm eleven times over the year, totalling $84,500 in payments, but a bookkeeper covering a leave had coded every one of those eleven invoices to Materials & Supplies instead of Subcontract Labour. When the T5018 aggregation query pulled from the labour account, that subcontractor never appeared in it at all.
The gap was not that the sub went unpaid or unreported to anyone — the $84,500 was fully paid and sitting in the general ledger the whole time. It simply was not going to appear on a T5018 slip, because the query that built the T5018 list only looked at one account, and none of these eleven invoices were coded to it.
A reconciliation pass built for the filing cross-checked every vendor with an active subcontractor file — one carrying a business number and HST registration on record — against the T5018 aggregation, regardless of which GL account its payments had been coded to. That surfaced an anomaly the account-based query alone could not: a vendor with a live subcontractor file, an HST number, and eleven invoices in the general ledger, showing zero in the T5018 total. Under s.238(3)–(4), the reporting period is fixed once chosen and the return is due within six months after the end of it — a gap caught before that deadline is a correction; one caught after is a late or incomplete filing.
The mis-coding itself was an easy mistake to make and a hard one to notice from inside the accounting system: a roofing sub’s invoice, describing shingles, underlayment and labour on one line, genuinely could be read as a materials purchase by someone unfamiliar with how this particular vendor normally billed. Nothing about the invoice was fraudulent or unusual on its own; the account it landed in was simply the wrong one for what the T5018 filing needed to see.
The eleven invoices were recoded to Subcontract Labour, and the roofing subcontractor was added to the year’s T5018 filing before the six-month deadline, with the full $84,500 correctly reported. The firm also changed how its T5018 aggregation runs going forward: matching against every vendor carrying an HST number on file, not only against payments already coded to a specific account, so a future miscoding cannot silently drop a vendor from the list again.
For the mirror-image problem — workers coded as subcontractors who should never have been on a T5018 list at all — see a contractor that reclassified nine long-term subs. For the filing mechanics themselves, see T5018 reporting and whether a payment gets a T5018 or a T4A.
An information return is a statement of what the payer reported, independent of whatever the subcontractor did with its own tax filings — a $84,500 gap in the GC’s own T5018 return would have been a compliance failure on the GC’s side regardless of whether the subcontractor separately reported the income correctly. Left uncaught until after the six-month filing window closed, the correction would have become a late or amended filing instead of an on-time one, for a gap that had nothing to do with the underlying payment being legitimate and everything to do with which account it happened to be coded to.
The tell is a vendor file that is active and complete — a real business number, a real HST registration, real invoices in the ledger — sitting at zero in a report that is supposed to be built from exactly that vendor’s activity. A T5018 aggregation built only from one GL account will miss anything coded elsewhere by mistake; reconciling against the vendor file itself, not just the account, is what catches a miscoding instead of assuming an empty total means no activity.
A 30-minute call is enough to tell you whether AI pays for itself here.
