Extracting Structured Fields From a Loan Payoff Statement

A payoff statement gives one number and an expiry date. Because the expiry date is almost never the day the money moves, the extracted record is only useful if it also captures the rate at which the number grows — and that rate is quoted on a day-count basis that the statement states and that changes the answer.

What a payoff statement is for

A payoff statement, or payoff demand, is a servicer’s answer to “what do I owe to close this loan out entirely?” It is not a monthly statement and not an amortization schedule. It exists because the balance changes daily, so a single figure is meaningless without a date attached and a rule for what happens after it.

Here is a synthetic statement, laid out roughly the way servicers do:

Unpaid principal balance                      184,320.55
Interest paid through                         2026-03-31
Interest accrued 2026-04-01 to 2026-05-15       1,448.55
Payoff statement fee                               30.00
Recording / reconveyance fee                       45.00
Wire fee                                           25.00
------------------------------------------------------------
TOTAL PAYOFF, good through 2026-05-15         185,869.10

Interest rate                                     6.375%
Per diem interest (365-day basis)                  32.19
Escrow balance                                     912.40  (refunded separately)

The statement foots: 184,320.55 + 1,448.55 + 100.00 in fees = 185,869.10. That is the first check to run on an extraction, and it catches the most common failure — a fee line missed because it sat below a horizontal rule that the layout reader treated as a section boundary. Build the schema so the check is expressible: a list of charge lines with labels rather than three named fee fields, plus the stated total, plus an assertion that they agree. This is the same shape as any cross-field amount rule, and it is unusually reliable here because payoff statements are machine-generated and genuinely do foot.

Per-diem, and the divisor that changes it

Per-diem interest is the daily accrual on the unpaid principal. It is derived, so you can recompute it and check the statement against itself:

annual interest = 184,320.55 x 0.06375 = 11,750.4350625

365-day basis:  11,750.4350625 / 365 = 32.192972...  -> 32.19 per day
360-day basis:  11,750.4350625 / 360 = 32.640097...  -> 32.64 per day

Forty-five cents a day between the two. That sounds like nothing and is not: over a thirty-day delay it is $13.41, and over the life of a busy settlement desk it is a systematic bias in one direction. More to the point, if you extract per_diem: 32.19 without extracting the basis, you cannot tell whether the servicer computed it the way you are about to, so you have no way to detect a transcription error in either number.

Extract all four values and reconcile:

{
  "unpaid_principal": "184320.55",
  "interest_rate_annual": "0.06375",
  "per_diem": "32.19",
  "day_count_basis": 365,          // read from the statement, null if not stated
  "per_diem_recomputed": "32.19",  // derived: principal * rate / basis
  "per_diem_agrees": true
}

When the basis is not stated — and it often is not — solve for it instead of guessing: divide the annual interest by the stated per-diem and see which divisor comes back. 11,750.435 / 32.19 = 365.0, so the servicer used 365. That inference is sound, cheap, and belongs in code rather than in the prompt. If neither 360 nor 365 comes back cleanly, either the principal you extracted is wrong, the rate is wrong, or the loan has something else going on — a rate that changed mid-period on an adjustable loan, or interest computed on an average daily balance rather than the closing one. All three are worth a human look, and the recomputation is what surfaces them.

Projecting to a later closing date

The statement is good through 15 May 2026. Suppose closing moves to 2 June 2026. Count the days:

2026-05-15  ->  2026-05-31    16 days
2026-05-31  ->  2026-06-02     2 days
                              --------
                              18 days

additional interest = 18 x 32.19 = 579.42
projected payoff    = 185,869.10 + 579.42 = 186,448.52

On a 360-day basis the same eighteen days cost 18 × 32.64 = 587.52, eight dollars more. A settlement agent wiring the smaller figure leaves the loan open with a balance, which is a slow and expensive problem to unwind, so this is one of the places where being wrong in the cheap direction is worse than being wrong in the expensive one.

Two details in the day count are worth stating because they are where off-by-one errors live. First, the convention is usually that interest accrues on each day the loan is outstanding, so the count runs from the day after the good-through date to and including the payoff date — which is the eighteen above. A statement that says “add per diem for each day after 15 May” and a statement that says “through and including the date of receipt” can differ by one day, and one day is $32. Extract the wording, not your assumption about it. Second, funds received after the servicer’s daily cutoff are applied the next business day, and a wire on a Friday afternoon can post on Monday, adding three days nobody planned for.

What breaks the projection

Straight-line per-diem projection is correct only while nothing else happens to the loan. Three things routinely do:

• A scheduled payment posts in the gap. If the borrower’s regular payment is due 1 June and it clears, the principal drops by that payment’s principal portion, the accrued interest resets, and the per-diem itself falls slightly. The projected figure is then too high by roughly the payment amount. Most payoff statements carry a line saying whether payments due before closing are included or excluded from the quoted figure; extract it as an explicit boolean, because the two readings produce answers a whole monthly payment apart.
• The escrow balance. In the synthetic statement above, $912.40 sits in escrow and is marked as refunded separately rather than credited against the payoff. Some servicers credit it, some refund it after the loan closes, and the difference is not cosmetic: crediting it reduces the wire, refunding it does not. A schema field of escrow_balance with no escrow_treatment alongside it invites somebody downstream to subtract a number that was never meant to be subtracted.
• A prepayment penalty or a rate change. A penalty is often quoted conditionally — applicable only if the loan closes before a stated date — which makes it a conditional amount with a predicate, exactly like a conditional pledge installment. Carry the condition text with the amount.

The general rule that falls out of all three: never store the projected payoff as if it were a fact from the document. Store the statement’s own figures, store the projection inputs, and compute the projection at the moment somebody asks, with the closing date they are actually asking about. A projected number written into a record on Tuesday and read on Friday is wrong by three days of interest and carries no sign of it, which is a good argument for keeping extraction and reasoning in separate stages.

The fields that are not the payoff amount

Everything above concerns money. The rest of the statement is instructions, and getting them wrong wastes more time than getting the arithmetic wrong, because a correctly-computed wire sent to the wrong department still fails.

• Loan number as it must appear on the wire. Often formatted differently from the loan number in the letterhead — zero-padded, or with a branch prefix. Extract both and keep them distinct.
• Wire instructions: beneficiary bank, routing number, account number, reference line. A US routing number carries a documented mod-10 check digit with weights 3, 7 and 1 repeating, so it is one of the few fields on this document you can validate arithmetically before anybody sends anything — the general technique is on validating an identifier field with a checksum. Treat a failed check as a hard stop, not a warning.
• The expiry and re-quote language. “This payoff is void after 15 May 2026 and a new statement must be requested” means the projection is a working estimate rather than an amount you may rely on, and the record should say so.
• Whether the figure covers all liens held by this servicer. A second loan or a line of credit with the same servicer may need its own statement, and a payoff that quietly covers only the first lien leaves the property encumbered.

The payoff figure then reappears downstream, which gives you a free end-to-end check: on a settlement statement it lands on the seller’s side as a reduction in the amount due to them. The worked HUD-1 on the settlement statement page carries exactly the 186,448.52 derived above, and reconciling the two documents against each other is a stronger check than either one alone.