When analysts review financial statements for commercial property acquisitions, they don’t just read the numbers. They adjust them. The line items on a trailing twelve-month statement reflect how the current owner has been running the property, which is often different from how the property will perform under new ownership or professional management.

The standard adjustments are well-known in the field: remove one-time items that won’t recur, add back personal expenses the owner has been running through the property, add a management fee line if the seller is self-managing, adjust property taxes to reflect the buyer’s acquisition basis rather than the seller’s historical basis, and flag unusually low maintenance spend as a signal of deferred capex.

AI can read the financial statement. What it cannot do automatically is know that a management fee line is missing because the seller self-manages, or that a particular line item is a one-time legal settlement rather than a recurring cost. That knowledge comes from domain context — knowing what a normalized T12 is supposed to look like and comparing it to what’s actually on the page.

This is the normalization problem: the gap between reading a document and knowing what the document should say. It’s not unique to real estate. Any professional domain with standardized document formats and domain-specific adjustment conventions has a version of it. Tax returns, loan applications, clinical notes, financial models — all of these have things that trained readers know to look for that aren’t explicitly flagged in the document itself.

Tools that address the normalization problem directly are more useful than tools that just extract what’s there. The difference is building domain knowledge into the analysis layer, not just the reading layer. For a financial statement tool, that means knowing the five standard adjustments, checking for each one systematically, and surfacing what’s present, what’s missing, and what the normalized figure would be.

The interesting design question is where that domain knowledge lives. One approach is to encode it statically — the tool always checks for the same list of adjustments. This works well when the adjustment list is finite and well-understood, which it often is in mature professional domains. Another approach is to let the analyst specify what adjustments to apply, which keeps the tool general but puts the work of knowing what to check back on the user.

For a professional tool targeting a specific vertical, the static approach is usually better. The analyst shouldn’t have to tell the tool to check for a management fee on every deal. The tool should know that already.

+++