What does document analysis mean for a mortgage file?
A mortgage file is a collection of statements about the same borrower, the same property, and the same transaction. The statements come from different sources, and each source has its own format, its own level of detail, and its own incentives. The borrower writes one number on the application. The employer prints a different number on the paystub. The CRA prints a third number on the notice of assessment. The bank statement shows deposits that do not obviously match any of them. Document analysis is the disciplined process of turning that pile into a single coherent picture.
The process has four parts. Extraction is the first: names, dates, income figures, balances, addresses, and account numbers have to be pulled out of PDFs, scans, and photographs. Cross referencing is the second: the same fact has to be checked in more than one place, because a document read on its own almost always looks fine. Calculation is the third: ratios like GDS and TDS have to be built from the extracted numbers using the same rules a lender will use. Flagging is the fourth: the system has to surface the specific items that do not line up, rather than simply declaring the file good or bad.
Each part matters, but the second part is where most of the practical value lives. Extraction without cross referencing is just faster data entry. Calculation without cross referencing is just arithmetic on numbers that may not belong together. The discipline of comparing document against document is what turns a speed tool into a quality tool.
Which documents carry which facts?
Not every document answers every question. A good analysis system knows what to look for where, and it knows that some documents are more authoritative than others on specific points.
Paystubs and T4s are the primary source for employment income. A paystub shows current earnings, year to date income, the employer's name, the pay frequency, and sometimes the position or start date. A T4 shows what the employer reported to CRA for the full tax year. The two should tell a consistent story. If they do not, the difference is a question for the borrower, not a reason to assume either one is wrong.
Notices of assessment confirm total reported income and any balance owing to or from CRA. They also show RRSP room and, in some cases, information that affects how a lender views the borrower's overall financial position. A borrower who reports a high income but has a large CRA balance may simply have a payment plan, or there may be a deeper story worth understanding.
Bank statements are where deposits, withdrawals, and account behaviour live. They show whether stated income actually lands in the borrower's account, whether there is NSF activity, whether large deposits have an obvious source, and whether the account balances support the picture the rest of the file presents. They are also the place where a down payment often reveals itself, sometimes as a transfer from another account, sometimes as a gift, and sometimes as something that needs a letter of explanation.
Credit reports carry liabilities, payment history, and derogatory items. They show balances, limits, minimum payments, and whether the borrower has been late. A credit report may also reveal debts the borrower did not disclose on the application. The analysis system should compare those liabilities against the debts listed on the application and flag any gaps.
MLS listings and purchase agreements provide property details: address, list price, sale price, property taxes, condo fees if applicable, and sometimes the property type or zoning. These feed directly into the ratio calculations and into the lender's assessment of whether the property matches the loan request.
Where does the real value sit?
The value is almost entirely in cross referencing. Reading one document quickly is a convenience. Reading several documents and noticing that they contradict each other is where a broker earns trust and where a file avoids an embarrassing return from a lender.
Consider income. The application says one number. The paystub says another. The T4 says a third. The notice of assessment confirms a fourth. A useful analysis does not pick a winner. It presents all four numbers, explains why they might differ, and flags the ones that need clarification. The same applies to liabilities. The application lists three debts. The credit report lists five. The bank statement shows payments to a creditor not on either list. The analysis should surface the mismatch and leave the explanation to the broker.
The same principle applies to ratios. GDS and TDS are not complicated formulas. What makes them hard is getting the right inputs. The right inputs come from reconciled income, verified liabilities, and accurate property expenses. A system that does the ratios without doing the reconciliation is just a calculator. A system that does both, using the stress test a lender will apply, gives the broker a realistic preview of what the lender will see.
What can these systems not do?
The most important limitation is that document analysis cannot approve or decline a deal. Approval is a lender decision that involves risk appetite, policy exceptions, portfolio targets, and sometimes a conversation between the underwriter and the broker. Software has none of those things. Any tool that presents itself as making the decision is either overselling or misunderstanding its role.
Document analysis also cannot know a lender's appetite. One lender may accept a particular income structure. Another may not. One may have a policy on gifted down payments that differs from another. The system can read the documents and calculate the ratios, but it cannot tell you which lender will buy the file. That judgment belongs to the broker.
It cannot replace broker judgment on an unusual file. Most files are routine, but the ones that matter most are often the ones that do not fit a template. A borrower with a complex income structure, a recent job change, a non standard property, or a temporary credit event needs a human who can ask the right questions and present the file properly. The analysis tool's job is to give that human better information, not to remove the human from the process.
Finally, it cannot verify facts that are not in the documents. If a document is forged, incomplete, or outdated, the analysis will treat it as true. The system reads what it is given. It does not call the employer, visit the property, or ask the borrower follow up questions.
What should you ask a vendor?
If you are evaluating a document analysis tool for your brokerage, the marketing will focus on speed. Speed is nice, but it is not the only thing that matters. Ask these questions before you commit.
Does the system show its reasoning? A summary that says "income mismatch" is less useful than one that says "the paystub annualizes to $78,000, the T4 reports $72,000, and the notice of assessment shows $71,500." You need to see the numbers so you can decide what to do with them.
Does it handle Canadian conventions? GDS and TDS are Canadian ratios. The OSFI B 20 stress test is a Canadian rule. A tool built for another market may use the wrong compounding, the wrong qualifying rate, or the wrong treatment of property taxes and condo fees. Make sure the math matches what Canadian lenders expect.
Where does the data live? Mortgage files contain sensitive financial information. Understand the jurisdiction, the hosting provider, the encryption, and who can access the documents. If the vendor uses the documents to train general AI models, that is a separate question worth asking directly.
How does it handle real world documents? Borrowers send scans, photographs, and partially filled PDFs. A system that only works on clean, typed forms will let you down on the files that need the most help. Ask about handwriting, rotated pages, and mixed file formats.
Can you export the analysis? The output should fit into your workflow, not trap you in a proprietary format. Whether it exports as a PDF, a structured report, or data that feeds into your CRM, you should be able to keep a record of what the system found.
How does BrokerDam fit in?
BrokerDam includes an AI underwriter that reads the full application package and returns a broker facing summary: extracted facts, reconciled numbers, GDS and TDS with the stress test applied, and a list of specific flags with the reasoning behind each one. It does not approve or decline. It does not replace your judgment. It is built to give you a cleaner starting point before you send a file to a lender.
If you want to see how it handles a Canadian file, you can read more about the AI Underwriter here.