W-2 income verification is, from a document extraction standpoint, largely a solved problem. The form has a stable layout across employer payroll systems, the fields are labeled, and the income figures are direct totals. A capable extraction engine reads box 1 (wages, tips, other compensation), verifies it against prior-year history, and produces a reliable gross income figure in a few seconds.
Non-W-2 income is a different category of problem entirely. A self-employed borrower's qualifying income is not a single number from a single field. It requires reading multiple forms, applying program-specific calculation logic, and making judgment calls about what is and is not stable income. This is where extraction systems reach their limits, and where understanding those limits is as important as understanding the capabilities.
The 1099 borrower: multiple payers, no employer summary
A borrower who received 1099-NEC or 1099-MISC income in a given year may have received forms from five different clients. The lender needs total gross income from all sources, but the 1099 forms themselves only show the amount paid by that specific payer. There is no single summary document. The processor has to aggregate across all forms, then cross-reference against the Schedule C on the federal return to verify that the gross self-employment income is consistent.
Extraction handles this by reading each 1099 and building an aggregated income ledger. The challenge is matching those aggregate figures to Schedule C, which uses different terminology. Box 1 on a 1099-NEC is "nonemployee compensation," which flows to Schedule C line 1 as "gross receipts or sales." The values should be close, but they are not required to be identical: the Schedule C may include income not reported on 1099s (clients who paid less than the reporting threshold), or may include returns and allowances that reduce gross receipts. The extraction system has to recognize this is a reconciliation task, not an equality check, and flag discrepancies that warrant human review rather than automatically failing the income comparison.
Schedule C and the qualifying income problem
For Fannie Mae and Freddie Mac conventional programs, qualifying income for a self-employed borrower generally follows the Schedule C calculation: gross income minus business expenses, with certain non-cash deductions (depreciation, depletion) added back. The result, averaged over two years if available, produces the qualifying income figure.
The extraction task here is not just reading the numbers; it is identifying which add-backs apply under the relevant program guidelines. Depreciation (Schedule C line 13) is a standard add-back. Meals and entertainment are not added back. The business use of home expense is not added back in the same way depreciation is. When we built Maestro's Schedule C extraction, we had to decide how to handle the add-back logic: apply a default set of conventional add-backs and flag everything else for review, or present the raw extracted figures and let the processor apply program logic.
We went with the first approach as the default, with the raw fields accessible alongside. The reason is practical: processors who work high volumes of conventional files do not want to re-apply the same add-back logic to every Schedule C. They want the calculation done and the outliers flagged. But a processor working a non-QM file with different add-back rules needs the raw fields, not the conventional calculation.
This is a place where we are not saying conventional calculation is always correct. We are saying it is the right default for the majority of files, with the raw extraction available for cases where the processor needs to apply different logic.
Gig economy borrowers and the stability question
A borrower who drives for a rideshare platform and supplements that income with a few side projects has a document profile that looks superficially similar to a self-employed borrower: 1099s, Schedule C, potentially variable income across quarters. The extraction challenge is less about finding the income numbers and more about structuring them in a way that surfacing the stability question becomes easy.
Platform gig income tends to show strong seasonal patterns. A borrower who earns significantly more in summer months than winter months has variable income that is patterned, not deteriorating. Bank statement analysis is the secondary verification layer here: twelve months of deposits cross-referenced against the 1099 totals provides a month-level view of income consistency. Large swings in monthly deposit amounts relative to the 1099 total can indicate timing differences (platform payouts on a weekly schedule do not map cleanly to monthly bank statements) rather than income instability.
Where extraction reaches a hard limit with gig borrowers is the question of whether the income is likely to continue. A borrower who drove rideshare full-time for 18 months and then stopped for 6 months before applying has an extraction-readable income history that looks incomplete. The extraction can surface the gap. The judgment about whether that gap represents a career change, an injury recovery, or a deliberate pause requires human review. We document this clearly in the confidence scoring: extraction can tell you what the documents say, not whether the income pattern indicates future stability.
Rental income: Schedule E and the depreciation add-back
Rental income from Schedule E is a distinct extraction case with its own quirks. The key calculation for qualifying income is the reported net rental income or loss, plus the depreciation and depletion add-back from Schedule E Part I. Most conventional programs use a two-year average of this figure, which requires reading two years of Schedule E and producing a consistent line-item extraction.
The practical difficulty is that rental properties can appear in multiple ways across two years of returns. A property acquired mid-year in year one shows partial-year income in year one and full-year in year two. Extraction has to handle this case differently from a full-year-both-years property when calculating the two-year average. If the extraction system simply averages year one and year two gross rental income without accounting for the mid-year acquisition, it will understate the income potential of the property.
Schedule E also shows expenses that require careful handling. Mortgage interest, property taxes, and insurance are pass-through expenses that reduce the net rental income for tax purposes. Depreciation is a non-cash add-back. Repairs and maintenance are legitimate expenses but may vary year to year in ways that make a simple average misleading. Our extraction produces each line item separately rather than only the net figure, so the processor reviewing the output can see the composition of the expense structure.
The document volume problem at scale
A straightforward self-employed borrower application typically involves the following: two years of 1040 federal returns with all schedules, two years of 1099s from major clients, three months of business bank statements, three months of personal bank statements, and a year-to-date profit and loss statement prepared by the borrower or their accountant. That is routinely 50 to 80 pages of documents before any follow-up requests.
When a processor manually works through that document stack to identify and verify income, the task is genuinely time-intensive, commonly taking two to three hours for a complex self-employed file. The extraction pass does not eliminate that time entirely, but it reorganizes it. Rather than spending the first hour locating numbers across documents, the processor reviews a structured extraction output and verifies the flagged items. The analytical time remains; the organization time compresses.
Where human judgment stays essential
We want to be direct about the cases where extraction confidence is low and human review is not optional. A borrower with income from three different Schedule C businesses, each at a different stage of maturity, presents a calculation problem that requires the processor to make a program-specific determination about which businesses qualify and how to aggregate income across entities. The extraction surfaces each Schedule C separately with the relevant figures. The determination of qualifying income in this scenario is a human call that the extraction is designed to support, not replace.
The same applies to borrowers with significant business-use-of-home deductions, to borrowers with Section 179 expensing that creates large one-year swings in Schedule C net income, and to borrowers whose prior-year income looks substantially different from the year-to-date P&L. These are cases where a confidence flag in the extraction output is the signal to a reviewer that this specific aspect of the income analysis requires underwriter judgment, not just processor review.
The goal of Maestro's extraction for non-traditional income is to make the human reviewer's job better scoped, not to substitute for the reviewer. The structured output converts a document navigation problem into a review and judgment problem. Those are very different tasks, and only the first one is amenable to automation without risk of error.