Extract, validate, then route for approval — and never let the last step be automatic. Utility invoices are a good extraction target because their layout is stable and the fields are predictable. The validation worth building is not “does this look right” but the specific information the GST/HST rules require before an input tax credit can be claimed, which changes with the size of the invoice. Get that right and the month-end accrual stops being a manual exercise.
Key takeaways
A portfolio generates a predictable pile every month: electricity, gas, water, sometimes a sub-metering provider’s statement per building. The work is not thinking; it is reading the same six fields off a hundred documents, coding them to the right property and period, spotting the one that has doubled, and getting them into the ledger before the owner report runs. That is an extraction problem with a validation layer, which is the shape of problem current tooling handles well.
Two families of model, and it is worth knowing which you need. Microsoft documents prebuilt models you can use to add intelligent document processing to your apps and flows without having to train and build your own models, including a prebuilt invoice model. Usefully, the field schemas are typed: for prebuilt models field schemas are defined and maintained by Microsoft, and common fields are mapped to specific types — for example, InvoiceDate is returned as a date type and SubTotal as a currency type — so normalization happens automatically. Where a supplier statement does not fit, custom models are trained to extract labeled fields from documents and standalone custom models can be combined to create composed models, with custom neural models for mixed-type documents and custom template models for static layouts. A utility statement is usually a static layout, which is the cheaper case.
What none of this does is decide whether the charge is correct. Treat the output as a populated form awaiting review, and design the review so it is fast: show the extracted value next to the region of the page it came from, and let a person confirm a screenful at a time.
For a GST/HST registrant, the point of holding the invoice is the input tax credit, and the information you must have is prescribed and tiered. Under the Input Tax Credit Information (GST/HST) Regulations, where the total shown on the supporting documentation is less than $100, the required information is the name of the supplier or intermediary, or the name under which they do business, the date of the invoice, and the total amount paid or payable. Where it is $100 or more and less than $500, the supplier’s registration number assigned under section 241 of the Act is also required, along with the tax information for the supply. And where it is $500 or more, the information above plus the recipient’s name or the name under which the recipient does business, the terms of payment, and a description of each supply is required.
Those thresholds are the validation rule to encode, and they are worth checking against the current regulation rather than memory — the figures have not always been what they are now. The same regulations define supporting documentation to include an invoice, a receipt, a credit-card receipt, a debit note, a book or ledger of account, a written contract or agreement, and any record contained in a computerized or electronic retrieval or data storage system, which settles a question people still ask: a properly captured electronic record is documentation.
Retention is the other statutory constraint. A person carrying on a commercial activity in Canada must keep all records that are necessary to enable the determination of the person’s liabilities and obligations and retain them until the expiration of six years after the end of the year to which they relate, and where records are kept electronically must retain them in an electronically readable format for that period. Our sister firm covers the practical side in what records are needed to support an HST claim in Ontario.
A processing pipeline that holds up
Capture. One inbox or supplier portal pull per utility, with the original PDF stored unmodified and hashed.
Extract. Supplier, account number, service address, period start and end, consumption, charges by line, tax, total, due date.
Validate. Threshold rules for the tax information required, period continuity against the last bill for that meter, and a variance check against the same month last year.
Route. Clean invoices to the approver queue in bulk; exceptions individually with the reason stated.
Post and keep. Ledger entry with the document attached to the line, retained for the full statutory period in a readable format.
Ontario electricity bills follow a published shape, and coding to it makes recharges and owner reporting far easier to explain. The Ontario Energy Board sets out that a bill carries an Electricity line, which is the cost of the electricity used during the billing period, a Delivery line covering the cost of moving power, which includes a Customer Service Charge, a fixed charge that is the same amount no matter how much electricity is used, and a set of Regulatory Charges, which group the Wholesale Market Service Charge and the Rural or Remote Electricity Rate Protection charge. The Board notes that it sets rates once a year on November 1 for residential and small business customers buying from their utility — a date worth having in the variance rule, so the November step does not generate a portfolio-wide exception storm.
Buildings with unit sub-metering add a second document type. The OEB’s Unit Sub-Metering Code sets out the minimum conditions and standards that a licensed unit sub-metering provider must meet when providing unit sub-metering services on behalf of a master consumer, and the Board records that the current version was last revised on August 18, 2025. Where a mixed-use building is involved the metering arrangement itself can be the problem rather than the invoice — our sister firm explains why a mixed-use building needs separate utility metering.
Payment is a decision. An extraction model that misreads a decimal, or a supplier that bills twice, produces an error that automation will execute faithfully. Keep a person on release, and make the reviewer’s job about exceptions rather than re-keying: clean invoices approved in bulk, anything failing a validation rule presented on its own with the reason and the page region highlighted.
The following is illustrative — a composite of how the workflow is usually assembled, not a measured result.
A manager with 22 buildings receives roughly 90 utility documents a month. Each supplier emails to a dedicated address; a job stores the original, runs a template model, and writes a structured record. Validation then runs four checks: does the service address match a known meter, does the period follow on from the last bill for that meter without a gap or overlap, does the document carry the tax information its value requires, and is the total inside a tolerance of the same month last year.
Everything that clears all four checks lands in a bulk approval queue coded to property and period. Everything that does not surfaces individually with the failed check named: a water bill covering seven weeks instead of four, an electricity bill up sharply because a vacant suite’s baseboards ran all month, an invoice over $500 missing the terms of payment. The bookkeeper works the exceptions rather than re-keying the whole stack, and the accrual for month end is already correct when the owner reports run. How large the exception pile is depends entirely on your suppliers — measure it, do not assume it.
It can prepare the payment run. Releasing funds should stay with a person, with the usual segregation between whoever approves and whoever pays. The failure mode is not the model being wrong occasionally; it is a wrong payment executing before anyone looks.
The extraction is the easy part; the entitlement is not. What can be recharged, and on what basis, depends on the tenancy agreement and on provincial rules about metering and services. Settle that question before you automate the recharge, not after the first dispute.
Usually only for the odd supplier whose statement is genuinely unusual. Start with a prebuilt invoice model, measure where it falls short on your own documents, and train a template model for the two or three suppliers that account for most of the corrections.
Utility data feeds two other workflows directly: monthly owner reports and, where the bills point at a failing asset, preventive maintenance scheduling.
A 30-minute call is enough to tell you whether AI pays for itself here.
