Debt-to-income ratio is one of the most fundamental calculations in mortgage underwriting. Front-end DTI (housing expense divided by gross monthly income) and back-end DTI (total monthly debt obligations divided by gross monthly income) are calculated for every application and compared against program limits. For conventional loans, Fannie Mae's back-end DTI ceiling is generally 45 percent, with automated system approvals possible up to 50 percent in some cases. FHA allows up to 57 percent in many circumstances.
Given how central DTI is to the underwriting decision, the frequency with which it comes back as a condition is notable. In the files we have reviewed, income or liability errors that affect the DTI calculation appear often enough that they have become one of the first things we look at when building a pre-underwriting report. The errors are not always large, but a DTI that should be 43 percent calculated as 41 percent can be the difference between a file that clears underwriting on the first pass and one that generates a condition requiring resubmission.
The income side: where the numbers get complicated
The most common income-side errors in DTI calculation fall into a few recurring patterns.
Using annual income where monthly is required. This sounds like an obvious error, but it appears more often than you might expect, particularly when a processor is manually transcribing from a W-2. Box 1 of a W-2 shows annual wages. The DTI calculation requires gross monthly income. Dividing by 12 is not a difficult step, but under volume pressure with multiple files open simultaneously, the wrong value gets entered. The resulting DTI is dramatically understated, which flags at underwriting but only after the processor has moved on to other files.
Averaging income across an incorrect period. Fannie Mae and Freddie Mac guidelines for self-employed borrowers generally require a two-year average of qualifying income from Schedule C or Schedule E. If the prior year's return has not been filed yet and only one year of data is available, the calculation method changes. Using a single-year figure when two years are required, or inadvertently averaging three years of data when only two apply, produces an income figure that does not match what underwriting will calculate.
Missing a secondary income source. A borrower with a W-2 job and a part-time 1099 income source has two income streams that both need to be included in the gross monthly income figure. If the 1099 income appears only on the Schedule C and the processor is primarily working from the W-2, the secondary income may not be captured. This understates the income and inflates the DTI relative to what underwriting will calculate from the complete file.
Inconsistency between the 1003 and the income documents. The borrower's stated income on the 1003 and the income calculated from their supporting documents are often slightly different, for legitimate reasons: the 1003 reflects what the borrower believes they earn, and the documents reflect what tax and payroll records say. When a processor uses the 1003 figure rather than the document-calculated figure as the basis for DTI, they get a number that underwriting will not agree with.
The liability side: what gets missed in manual review
Liability errors are less common than income errors in the files we have seen, but they tend to be harder to catch because liabilities come from a wider range of sources.
Omitting installment loans close to payoff. A borrower with a car loan that has four remaining payments may be tempted to leave it off the liabilities section of the 1003, and a processor who does not cross-reference every liability against the credit report may miss it. Under most conventional guidelines, an installment debt with 10 or fewer months remaining can be excluded from the back-end DTI calculation, but only if it appears in the file and the documentation supports the payoff timeline. A liability that is simply absent from the liabilities section entirely is different from a properly documented near-payoff exclusion.
Treating minimum payments on credit cards inconsistently. Back-end DTI includes the minimum required payment on revolving accounts, not the full balance. If a processor uses the outstanding balance rather than the minimum payment for a credit card account, the DTI is overstated. If they mistakenly use the minimum payment for an installment loan (rather than the contractual monthly payment), it is understated. These are small errors per account, but a borrower with four revolving accounts and two installment loans has six liability line items where this error can occur.
Missing deferred student loans. Student loans in deferment or forbearance still need to be included in the DTI calculation under most conventional guidelines. Fannie Mae currently requires using 1 percent of the outstanding balance as the assumed monthly payment if the actual payment amount is not listed on the credit report and the loan is deferred. If a processor sees "deferred" on the credit report and treats it as zero liability, the DTI will be understated relative to what underwriting will calculate.
Why consistent extraction prevents these errors
The common thread across income and liability errors is that they arise from the synthesis problem: DTI calculation requires reading multiple documents, identifying the relevant figures in each, and combining them according to program-specific rules. Manual data entry at each step introduces the opportunity for each type of error described above.
Extraction solves the document reading step consistently. When the income and liability figures are extracted from the source documents and presented in a structured format alongside the document they came from, the processor's task changes from "find and transcribe all relevant figures" to "verify that the extracted figures look correct and apply the appropriate calculation logic." That is a fundamentally different cognitive task, and it is one that is much less likely to produce the specific error types described here.
We want to be clear that extraction does not eliminate the need for calculation judgment. Whether to include a deferred student loan at 1 percent of balance or at the documented payment amount is a program-specific decision. Whether a borrower's self-employment income qualifies based on two-year history requires reading the two years together and applying the relevant guidelines. Extraction provides the inputs. The calculation and its program-specific application are still the processor's responsibility.
The cost of a DTI condition at underwriting
A condition returned from underwriting for a DTI error typically requires the processor to go back through the income documents, recalculate, update the LOS, and resubmit the file. Depending on the underwriting queue at the lender, that cycle can add three to five business days to the timeline.
For the loan officer, a DTI condition on a file they already reviewed and submitted is also a quality signal. Repeated conditions from the same processor, or across a team, on a calculable element like DTI suggests a systematic issue in the pre-underwriting workflow rather than an isolated error. Catching the calculation in the pre-underwriting pass, before the file goes to underwriting, removes the cycle entirely. That is not just a time saving for the current file; it is a process quality improvement that compounds across every file in the pipeline.
The goal of the pre-underwriting DTI check in Maestro is exactly this: compute the DTI from the extracted documents, flag any material discrepancy with the figure on the 1003, and surface any liability exclusions that require documentation. Not to approve or decline the application, but to put a consistent, document-grounded DTI calculation in front of the processor before they submit, so the first thing underwriting sees is the same number the processor intended.