Repricing the analyst. What agentic AI actually takes off the desk.

A Frontier paper on the economics of ERP reporting work, with one capability worked end to end.

Executive summary

• A NetSuite reporting analyst's salary buys three different kinds of work, and only one of them is scarce.
• Retrieval and arithmetic — pull the record, run the query, do the multiplication, write down the working — is the layer agents now do in seconds, inside the record, read-only.
• Judgment — what the number means, which deal to go look at, what to say in the room — is the layer that was the reason to hire the person.
• The worked example is close probability. NetSuite's probability field holds whatever a rep typed, whenever they typed it. One SuiteQL call and four weighted factors produce a second number carrying every factor's contribution in points.
• An illustrative quote — 22 days open, $48,000 — scores 57.8/100. A dated read-only run against a sandbox sales order scored 79.0/100 on 2026-08-20.
• The model publishes its own ceiling: on an uncalibrated account a quote cannot score above 73.6 or below 35.4. It is a ranking, not a probability, and it says so in every answer.
• No price appears in this paper, and no hours-saved figure. Neither survives being asked for a source, so neither is written.
• The seam does not move. The score makes a question askable. You ask it, and you sign the forecast.

The line item.

Somewhere on every NetSuite org chart there is a job that consists of getting numbers out of the system and into a form somebody can act on. Sometimes it has a title. More often it is a standing slice of a controller's week.

Read the job honestly and the money is not buying a single skill. It is buying a bundle, priced at the rate of its scarcest component.

Three layers in one salary.

Retrieval. Find the record. Know which table it lives in, which status codes mean what on this tenant, which subsidiary column is populated and which is aspirational. Export it.

Computation. Apply the arithmetic. Weight the pipeline, bucket by value, count the customer's prior deals, multiply, sum, round. Rebuild it next month because the workbook drifted.

Judgment. Decide what the number means. Decide which three deals to go look at. Decide what to tell the board when the forecast moves, and stand behind it when somebody asks why.

Only the third layer is scarce. The first two are scarce only because they arrive attached to the third — one person does all three, so all three bill at the judgment rate. That is the pricing error, and it has held for as long as ERP reporting has been a job, because nothing could do retrieval and computation with the working attached. Something can now.

The claim here is narrow and testable: agents reprice layers one and two to near zero, and leave layer three exactly where it was. What follows is one capability worked end to end, so the claim can be checked rather than believed.

One deal, scored.

NetSuite has a probability field on quotes and opportunities. It is a good field. It holds whatever the salesperson typed into it, on the day they typed it.

Most reps never fill it in. The ones who do fill it in once, at creation, and nothing recomputes it as the deal ages — a quote can sit at "75%" for eleven weeks while every observable signal around it decays. When FP&A rolls a weighted pipeline off that column, the weighting is a snapshot of sales optimism at an arbitrary past moment, carried forward into a cash forecast people plan headcount against.

Overruling the rep is the wrong fix. The fix is a second number, computed the same way every time from attributes nobody types, and then the gap between the two. Where they agree, the line rolls up clean. Where they diverge, you have found the deal worth a conversation.

The second number is one SuiteQL call against the record, plus a correlated subquery counting that customer's decided quotes over the last 24 months. This is the statement as it ships:

SELECT
    t.id                                  AS deal_id,
    t.tranid                              AS deal_num,
    t.trandate                            AS deal_date,
    t.foreigntotal                        AS deal_value,
    t.probability                         AS rep_probability,
    BUILTIN.DF(t.entity)                  AS customer,
    t.entity                              AS customer_id,
    BUILTIN.DF(t.subsidiary)              AS subsidiary,
    BUILTIN.DF(t.status)                  AS status_label,
    t.status                              AS status_code,
    FLOOR(SYSDATE - t.trandate)           AS days_open,
    (SELECT COUNT(*)
       FROM transaction p
      WHERE p.entity   = t.entity
        AND p.type     = 'Estimate'
        AND p.status  <> 'A'
        AND p.trandate >= ADD_MONTHS(SYSDATE, -24)) AS prior_decided
FROM transaction t
WHERE t.id = {int(record_id)}

That last line is the record you have open, int-coerced on the way in.

Two details cost time if skipped. FLOOR(...) matters — SYSDATE - t.trandate is fractional days, and an unfloored 12.7 lands in the wrong age band. And prior_decided deliberately does not split won from lost: which status code means "won" differs by tenant, and the factor only needs to know whether this customer has transacted before.

Four weighted factors turn that row into a score:

composite = f_age·0.40 + f_size·0.25 + f_history·0.20 + f_subsidiary·0.15
score     = composite × 100

Pipeline age carries 0.40 — it is most of the model. Past fifty days a quote essentially stops closing, and the factor drops to 0.05. Age is also the only factor anyone can act on; the other three are properties of the deal you were handed.

Quote / opportunity, days_open	f_age
under 13	0.80
13–35	0.50
36–49	0.20
50 or more	0.05

A sales order runs a different curve, because a sales order has already been won — scoring one measures fulfilment risk, not win probability:

Sales order, days_open	f_age
under 30	0.95
30–59	0.85
60–89	0.70
90 or more	0.50

Deal size carries 0.25 — historical win rate by value quartile. 74.4% in the bottom quartile against 47.7% in the top: large deals convert materially worse, and the factor is the measured rate rather than a penalty somebody chose.

deal_value	f_size
up to $5,673	0.744
up to $17,090	0.674
up to $62,356	0.616
above $62,356	0.477

Customer history carries 0.20, straight off prior_decided: 0 prior decided quotes → 0.678, 1–5 → 0.645, 6 or more → 0.603. The direction is counterintuitive and it is real — in the fitted data, brand-new customers scored slightly better than heavily-transacted ones, most likely because a long history carries a long tail of quotes that were never going to land.

Subsidiary carries 0.15, and its fallback is the most important number here. The split was measured on one account with two named subsidiaries. On any other tenant neither name matches, so the model uses 0.630 — the overall base win rate — and says the subsidiary factor is uncalibrated. Picking a measured branch on an account it was never measured on would import a win-rate assumption up to 16 percentage points off the base: about 2.4 points on the composite, every one of them invented.

Score to tier: 70 or above High confidence · 50–69 Moderate · 30–49 At risk · below 30 Low probability.

Here is the whole computation on an illustrative quote — 22 days open, $48,000, a customer with 3 decided quotes in the last two years, on a subsidiary the model was not fitted on:

Factor	Observed	Score	Weight	Contribution
Pipeline age	22 days open	0.50	0.40	20.00
Deal size	$48,000 (third quartile)	0.616	0.25	15.40
Customer history	3 prior decided quotes	0.645	0.20	12.90
Subsidiary	uncalibrated → base rate	0.630	0.15	9.45
Composite				57.75 → 57.8

57.8/100, Moderate. Weighted value $27,744 — deal value × score ÷ 100, the number a forecast actually rolls up. Age is carrying the loss: at 22 days the quote has already dropped out of the top age band — 0.80 — and it drops again at day 36. The lever is speed, and it is the only lever on the table.

Four multiplications and a sum, shown. That is layer two, and it took the length of one table.

The dated run.

On 2026-08-20, a read-only run against an open sales order in a NetSuite sandbox returned 79.0 out of 100 — near the top of the band a sales order can reach, which is what a young, in-SLA booked order should look like. The evidence is a captured answer screen, not a recollection.

Separately, on 2026-08-21, an end-to-end test covering the delivery rails — the panel loads inside the record, one question goes out, one completed quantified answer comes back — passed in 41.6 seconds, with a deliberately-failing run first to prove the assertion bites. The test asserts the rails, never the score. Scoring correctness is the model's problem, not the plumbing's, and conflating the two is how green suites end up meaning nothing.

Three things about that run are the point:

• It happened inside the record. A score you have to leave the transaction to get is a score nobody asks for.
• It wrote nothing back. No field, no custom record, no transaction. Nothing downstream can start consuming a model output as though a person entered it, and the number cannot go stale on a record while the deal moves underneath it.
• It arrived with the driver table. The composite is the least interesting column. Which factor cost the deal its points is the answer.

What the model refuses to say.

This is the section most papers leave out, and the one that decides whether the rest is usable.

The output is bounded, and the bounds are published. Every factor is bounded and the weights are fixed, so the composite is bounded too. On an account where the subsidiary factor falls back to the base rate, a quote cannot score above 73.6 or below 35.4; a sales order cannot score above 79.6 or below 53.4. "Low probability" is therefore unreachable in practice, and "High confidence" opens only in the last few points of the quote range. Read a 68 as near the top of what this model can say, not as 68%. Two quotes at 44 and 61 are telling you something real about which is in more trouble. Neither is telling you that 61 of a hundred such deals will close.

The constants are borrowed, and the answer says so. Every weight, threshold and win rate above was fitted on one account's history: 344 decided quotes and more than 211 won deals over a 24-month lookback, measured in March 2026 on a two-subsidiary US/Canada distributor. The mechanism transfers — age dominating, large deals converting worse, the shape of the decay are ordinary patterns. The quartile boundaries and win rates belong to that account. If your average deal sits far outside $5.7K–$62K the size factor degenerates: every deal lands in the same bucket and contributes an identical 11.9 to 18.6 points across the whole pipeline, and a quarter of the weight becomes a constant. The answer flags that rather than quietly continuing to score. Recalibrating means re-running the analysis against your own decided history — a real job, not a constant to nudge.

It sees four attributes. No competitor, no budget cycle, no champion, no email thread. When the score disagrees with what you clearly believe, that is usually the model missing a field rather than the model knowing better.

Stating provenance inside the answer is a design decision, not modesty. A score that arrives without it gets treated as the system's belief about the future, and you have no way to discount it. A score that arrives with it can be used at the weight it deserves.

Where the repricing actually lands.

Set the layers against the rate they bill at.

Layer three does not reprice. Deciding which three deals to chase, and defending the forecast when it moves, is the same work at the same rate. Nothing above touches it.

Layers one and two reprice hard. Retrieval is a query. Computation is four multiplications and a sum. Both run in the record, on demand, with the working attached — and the working is better than the analyst's, because the analyst's constants live in a workbook nobody publishes and these are on the page above.

The size of that repricing is a number, and this paper does not print it.

There is no salary figure here, no category list price, and no price for Frontier. Frontier holds internal figures for all three. None of them carries an external citation, and a paper whose argument is publish your constants does not get to rest on three unpublished ones. The structural claim does not need them: the two layers that used to bill at the judgment rate now cost a query, and the layer that was worth the rate still is.

There is no hours-saved number either. The obvious next line — "this saves an analyst N hours a week" — is not written, because nobody has measured it on this capability. When a measured figure exists it will carry the account, the date and the method, exactly like the 79.0 above.

The seam holds.

Comparing the score to what the salesperson typed is the most useful thing this capability does, and the easiest thing to overstate.

Where they agree, say so. Agreement is a real signal, and the one that lets the line roll up without a caveat.

Where they are wide apart, say what each one knows. The model sees four historical attributes. The rep has been in the room. A rep at 15% against a model at 65 usually means the rep knows something structural — a competitor, a budget freeze, a champion who left — that no NetSuite field records. That is not optimism being detected. That is the absence of a field.

Never call the rep wrong. The productive frame is what would have to be true: "on age, size and customer history this one sits near the top of the range the model can produce. At 15% you are saying it is unlike the deals that look identical to it on paper. What is the blocker?"

That question is the output. The score is what makes it askable. You ask it, and you sign the forecast. The repricing is of the retrieval and the arithmetic — the part of the analyst's day that was never the reason to hire the analyst.

What to check before believing any of this.

A paper arguing for receipts should be checkable. Five things to demand of any agentic reporting claim, this one included:

1. Ask for the query. If the vendor cannot show the statement that produced the number, the number is a guess wearing a font.
2. Ask for the contribution column. A composite without per-factor contributions cannot be argued with, which means it cannot be used.
3. Ask where the constants came from, and on whose data. "Fitted on your account" and "fitted on an account" are different products.
4. Ask for the ceiling. Any bounded model has one. A vendor who has not computed theirs has not read their own model.
5. Ask what it writes back. Read-only is a design position with consequences — scores that cannot go stale, and outputs nothing downstream mistakes for a human entry.

The bottom line.

A close probability score is not a forecast. It is a historical base rate from a comparable account, applied to four things NetSuite already knows about one open record, delivered where that record lives and never written back to it. Used as a second opinion against a typed field, and as a ranking that says which three deals to go look at, it costs one query and four multiplications — cheap enough to run on every deal you care about.

That is the shape of the repricing. Not an analyst removed — a bundle unbundled. The retrieval and the arithmetic fall to the price of a query. The judgment stays with the person who signs the number, and it is worth more once the two layers under it stop being guesswork rebuilt monthly in a spreadsheet.