Skip to content
In the works

Borrower ACH through a licensed payment partner. Get notified

Mortgage escrow software: what an escrow analysis has to produce

An escrow analysis is not arithmetic on a tax bill. It projects a full year of disbursements, finds the lowest point the account would hit, adds the cushion, and turns the result into a new payment plus a shortage or a surplus you can send a borrower.

8 min read
  • escrow
  • compliance
  • servicing

"Escrow analysis" gets used loosely enough that it is worth being precise about what the term actually requires. A lot of what passes for one is a current tax bill and a current insurance premium, added together and divided by twelve. That is arithmetic. An analysis is a projection, and the difference shows up the first time a tax bill changes mid-cycle.

This walks through what an analysis has to compute, in the order it has to compute it, grounded in Regulation X at 12 CFR 1024.17, published by the Consumer Financial Protection Bureau at consumerfinance.gov, the primary text read this run and accurate as of October 2026. Whether this regulation reaches a specific private loan depends on the transaction and the parties involved, which is a legal question for an attorney rather than something this article or any software decides. The mechanics below describe how the aggregate accounting method computes regardless of whether a particular loan is covered by the federal rule.

The year does not start in January

The first thing an analysis has to get right is which twelve months it is even projecting.

Under 12 CFR 1024.17(b), an escrow account computation year is a 12-month period the servicer establishes for that account, beginning with the borrower's initial payment date. A loan that closed and began payments in April runs its escrow cycle April to April, every year, for as long as the loan exists. The annual escrow account statement is due within 30 days of the end of that cycle, not at calendar year end, under 1024.17(i). Two loans secured by the same property, closed on different dates, can sit on entirely different computation years with no overlap. Software that silently assumes every escrow account runs January to December is wrong about the one date that anchors everything else in the analysis.

What gets projected, and in what order

Regulation X describes the aggregate accounting method at 1024.17(d)(2)(i), and it runs in three distinct steps rather than one calculation.

First, the servicer projects a trial running balance for the account across the entire upcoming computation year, estimating that each disbursement is made on or before the earlier of a discount deadline, if one applies, or the deadline to avoid a penalty. That is twelve months of real dates: a county tax installment due in one month, a hazard insurance premium renewing in another, not a single lump sum.

Second, the servicer examines those twelve monthly trial balances and finds the lowest one, which will typically be negative right before the largest disbursement of the year hits. It then adds to the very first monthly balance an amount just sufficient to bring that lowest point up to zero, and adjusts every other monthly balance in the projection to match. This is the step that actually behaves like an analysis instead of arithmetic: the required payment is sized to the account's low point across the full year, not to any single month's bill.

Third, the servicer adds the cushion on top of every monthly balance. The cushion is capped: it may be no greater than one sixth of the estimated total annual disbursements from the account, under 1024.17(c)(1)(ii). That cap is what keeps the low-point-plus-buffer calculation from quietly becoming a larger reserve than the rule allows.

The output of those three steps is a monthly escrow payment. Compare it against what the account currently collects and you get either a shortage or a surplus, which is where the analysis stops being internal math and starts being something sent to a borrower.

What comes out the other side

A surplus of $50 or more gets refunded to the borrower within 30 days of the analysis, provided the account is current, under 1024.17(f)(2)(i). Anything smaller than that threshold is not required to go back as cash, though nothing stops a servicer from returning it anyway.

A shortage smaller than one month's escrow payment gives the servicer three choices under 1024.17(f)(3)(i): let the shortage stand and do nothing about it, require the borrower to repay it within 30 days, or spread repayment over at least a 12-month period. Those are options the regulation hands to the servicer, not a single outcome the rule mandates, which is worth knowing before assuming every shortage gets the 12-month treatment by default. A shortage of a full month's payment or more is a different case the same section addresses separately, and a servicing agreement or an attorney is the place to confirm which provision governs a specific account.

The annual escrow adjustment walks through how this produces a new monthly figure and a borrower notice inside a loan's Escrow tab, including the shortage and surplus outcomes described above.

When the tax bill changes before the cycle is up

An analysis that runs once a year on schedule is still wrong for however many months pass between a tax bill changing and the next scheduled analysis. A county reassessment, a homestead exemption falling off, or an insurance renewal coming in higher than last year all move the real annual disbursement total immediately, while the account keeps collecting last year's payment until someone reruns the numbers.

Rerunning early does not mean waiting for the next computation year to start. The same aggregate method runs again from the date the new figure is known, projecting disbursements forward from that point rather than from the original anniversary, and produces an updated monthly payment the same way a scheduled analysis would. The annual escrow adjustment again is the practical version of this: pick the date the new tax figure became known, and get the new monthly amount and any catch-up shortage from that date forward rather than from January or from the original computation year's start.

Where the real disbursement figures come from

Every step above depends on having the right annual disbursement figures to project in the first place. A cushion calculated correctly off a wrong tax total is still wrong, and a stale tax bill is one of the more common ways a private lender's escrow analysis goes bad quietly.

AI-powered escrow analysis covers how NoteHarbor pulls current county tax figures directly from the public record rather than relying on whatever was typed in last year, with a pattern-based fallback extractor when that is unavailable, and a manual override for a figure you would rather pin yourself. The method that actually ran is recorded against the account, so it is visible later which number came from where.

What to test on a loan whose tax bill moved

One test, on one real loan, settles most of what matters. Take a loan whose tax bill genuinely changed this year and run the analysis on it. Confirm the projection is using that account's actual computation year, not a January reset. Check that the new monthly payment reflects the low point across the full twelve months rather than the current bill divided by twelve. Confirm the cushion added is capped at one sixth of the annual disbursement total. Then read the document the analysis actually produces: does it state the new payment and the shortage or surplus in language you could hand to a borrower as written, or does it need translating first.

If you would rather check the underlying payment math by hand first, you can build the month by month schedule the escrow payment sits on top of with the free amortization calculator. It is public and stays that way.

Where NoteHarbor sits

Stated plainly so it can be checked against anything else that claims to run an escrow analysis.

The analysis runs the aggregate method described above: a full twelve-month disbursement projection for the loan's own computation year, the low point raised to zero, the cushion capped at one sixth of the annual total, and a resulting payment compared against the current one to produce a shortage or surplus figure, with a borrower-ready shortage invoice behind it. Tax figures can come from a county scrape, a built-in fallback extractor, or a manual override you lock in place. NoteHarbor does not hold or move the money itself, and no funds pass through it: it computes the analysis and the disbursement schedule behind it, and the lender pays the county and the insurer the way they always did. This is job four of eight covered more broadly in loan servicing software for private lenders, which sets out the other seven. The private lender overview is the product version of this article, and the trial is 14 days with no card if you want to run the test above against a loan you already hold.

An escrow analysis is a projection with a specific shape, not a once-a-year arithmetic chore, and the shape is what keeps a payment from drifting wrong for months after a tax bill moves.

This article is general information, not legal, tax, or accounting advice. Whether 12 CFR 1024.17 applies to a given loan, and what a specific servicing agreement requires, depend on facts specific to the transaction and the parties. The regulatory figures above are accurate as of October 2026 and change. Talk to a licensed attorney about your own situation.

Common questions

What makes something an escrow analysis rather than arithmetic on a tax bill?

Arithmetic takes this year's tax and insurance bills and divides by twelve. An analysis does more: it projects every disbursement the account will make over the next computation year, finds the single lowest point the running balance would reach given the current monthly payment, and raises that low point to zero before adding the cushion back on top. The output is a new required monthly payment and, by comparing it to what the account actually holds today, a shortage or a surplus. A spreadsheet can do the division. Projecting the low point across twelve irregular disbursement dates is the part that goes wrong by hand.

Why doesn't my escrow analysis run on the calendar year?

Because Regulation X does not define the computation year that way. Under 12 CFR 1024.17(b), the escrow account computation year is a 12-month period the servicer establishes for that account, beginning with the borrower's initial payment date. A loan that closed in April runs its escrow cycle April to April, not January to January, and the annual statement goes out within 30 days of the end of that cycle rather than at year end. Two loans on the same property can sit on different computation years if they closed on different dates.

What happens if the analysis finds a shortage or a surplus?

A surplus of $50 or more is refunded to the borrower within 30 days of the analysis, as long as the account is current, under 12 CFR 1024.17(f)(2)(i). A shortage smaller than one month's escrow payment gives the servicer three options under (f)(3)(i): let it stand and do nothing, demand repayment within 30 days, or spread repayment over at least a 12-month period. Which option applies to a shortage of one month's payment or more, and what a given servicer's policy actually is, are questions the regulation and your own servicing agreement answer together, not something a single article can generalize.

What should I test before trusting software with a real escrow analysis?

Pick one loan whose tax bill changed and run the analysis on it. Confirm the projection covers the full twelve-month disbursement calendar for that specific account, not a flat current-bill-divided-by-twelve estimate. Check that the cushion applied is capped at one sixth of the projected annual disbursements rather than a larger buffer. Then read the document the analysis actually produces: does it state the new payment, the shortage or surplus figure, and the computation year it covers in terms you could hand a borrower without rewriting it.

Mortgage escrow software: what an analysis must do | NoteHarbor