The working journal / Building useful software

Why Car Deal Check keeps the math outside AI

AI can help read a dealer worksheet. The payment calculation should remain something you can inspect and check.

By Blutek Media · Published · Updated

  • AI
  • Product design
  • Car Deal Check

A dealer worksheet mixes several kinds of information: the vehicle price, optional products, taxes, trade-in figures, and financing terms. Reading it is one problem. Working out how those numbers fit together is another. Car Deal Check treats those as separate jobs.

When AI import is available, a model can turn a pasted quote or a photo into structured fields. That is a useful role for a language model: recognizing that a line labeled “cash down” belongs in the down-payment field, for example. It is also a place where mistakes can happen. An unclear scan, an unusual label, or two similar totals can produce an incorrect reading.

One misread zero, a different answer

Here is an illustrative parser test, not a customer quote or a financing offer. Set the selling price to $20,000, cash down to $2,000, and the term to 60 months. Use 0% APR, no trade, and explicitly confirmed zero taxes and fees so the arithmetic is easy to inspect.

Now suppose an import reads the down payment as $200. Both values are valid positive amounts. A check that asks only whether the result is a number will accept either. The calculator can perform its work correctly and still produce the wrong answer for the original quote.

Illustrative 0% APR test: only the parsed cash down changes
Input or resultCorrect readingMisread down payment
Selling price$20,000$20,000
Cash down$2,000$200
Taxes, fees, and trade$0$0
APR / term0% / 60 months0% / 60 months
Amount financed$18,000$19,800
Monthly payment$300$330

At zero interest, the calculation is principal divided by the number of payments: $18,000 / 60 = $300. The misread input adds $1,800 to the principal and $30 to each payment. That difference comes entirely from interpretation, not the payment formula.

The useful boundary is therefore between a proposed reading and an accepted input. Let the person compare the imported field with the source quote before treating it as a fact. A confident explanation cannot correct a missing zero on its own.

Missing is not the same as zero

The example deliberately supplies zero charges. An actual missing fee should not silently become zero. A blank field means the value is unknown; a confirmed zero means someone has established that the charge does not apply. Those states may lead to different questions even when a program could turn either into the same number.

The live manual calculator makes this distinction explicit in its instructions: leave unknown fields blank and add a named zero tax or fee when it is confirmed. It also keeps the worksheet amount financed separate from the itemized estimate. That separation lets a reader investigate a mismatch instead of overwriting one total to make the screen look consistent.

Cash due at signing is another possible ambiguity. It can include cash down, so adding both without understanding the labels can count the same contribution twice. The import step needs to preserve what the quote says, not invent a second contribution because it found a second currency amount.

Keep the calculation independent

Once the inputs are accepted, ordinary calculation code should own the results. The same values, rounding rules, and term should produce the same estimate. A generated explanation can discuss a fee or suggest a question, but it should not supply a competing payment amount.

This also gives the product a useful failure boundary. As checked on September 22, 2026, AI quote import is paused on the public tool, while the manual calculator, APR comparison, and trade-in tools remain available. The reader can still do the core task without a model response.

Keeping the parts separate makes testing more specific. Test extraction against the source document. Test calculation with known inputs and expected results. Test explanations for consistency with those results. One successful end-to-end example does not tell you which boundary will fail on the next quote.

Tests worth keeping

Start with the missing-zero case above and assert both the accepted input and the resulting principal. Then try an unknown fee, a duplicate charge, and a disagreement between the itemized total and the worksheet amount financed. Each case should produce a clear state the person can inspect, rather than a quietly repaired number.

For the calculation path, include zero interest, a changed term, and a change of one cent. Decide how monetary inputs and displayed rounding are handled and test those rules directly. For an import failure, check that the user can continue manually without losing already reviewed values. These are suggested regression cases, not a claim that every automated test is already implemented in the product.

The example isolates a software-design problem. Real transactions include more costs, and an estimate does not replace the lender's disclosures. The CFPB explains the costs that affect how much is borrowed, including taxes, fees, and upfront contributions.

For the broader interface walkthrough, read Car Deal Check: making a calculation explain itself. This article focuses on a narrower lesson: interpretation can save effort, but the important numbers still need a reviewable path from source to input to result.

Try the free Car Deal Check calculator

Share this article

LinkedIn (opens in a new tab)Email

Continue the conversation

A question, a different experience, or an idea for the next article? Send Jason a private response.

Share a question or experience
Where do you draw the line between AI and deterministic code?

Open this section to prepare the form.

Browse the full article archive