unpriced_usd_micros: legacy rows still inside Sume's debited total

unpriced_usd_micros is the captured amount of rows that have no price-book stamp, meaning legacy rows from before Sume stamped each charge. It is already counted in debited_usd_micros, so it is a breakdown of the debited figure and never an extra charge on top. The OpenAPI description (read 2026-10-11) says it in one line: counted in debited.

A new launch week is a good moment to learn this field. When a batch of recent models enters your reports, you want to know which part of the total you can trace to a stamped rate and which part you cannot.

Two fields, one total

The usage summary returns money in integer micros, where one million micros is one US dollar. The debited_usd_micros figure is the source of truth. The unpriced_usd_micros field is a slice of it.

A simple identity holds for reporting: stamped debited equals debited minus unpriced. The docs do not name a field for the stamped part, so compute it yourself from the two values, and label it as derived in any report.

A worked example in micros

Say a scope reports debited_usd_micros of 2,500,000 and unpriced_usd_micros of 400,000. The wallet paid $2.50 in total. Of that, $0.40 has no price-book stamp and $2.10 does. Those numbers are an illustration of the arithmetic, not data from any account.

If you report $2.50 plus $0.40 you would be double counting, and the error grows with every legacy row. The same rule applies to held and refunded: each is its own bucket, but unpriced is a view inside debited.

Why it matters for a cost-per-ad report

A cost-per-ad table divides spend by the number of finished ads. If part of the spend cannot be tied to a stamped rate, a per-ad average built from rates in the price tables will not match the ledger exactly. The mismatch is not an error in the ledger. It tells you to use the debited figure for the true cost and the price tables for forecasts.

For threads that mix old and new work, use the operation breakdown as well. A post on which step cost most in a thread shows how by_operation_type splits the same money.

Do not confuse it with settle_state unpriced

The word also appears as a settle_state value on usage rows. A reserved row in unpriced is a hold the settle sweeper still owns, according to the OpenAPI text. That is a hold, not captured spend, and it is counted in held. The summary field unpriced_usd_micros is about captured legacy rows. Same word, different bucket.

When a number looks off, read final first. If it is false, a hold is still open, and the final-false explainer tells you why. Only after that is it worth looking at the unpriced slice.

In practice, a finance reader wants three lines: debited, of which unpriced, and held. Print them in that order, with final next to them, and the report explains itself without a footnote. Keep the units in micros in the export and show dollars only in the presentation layer, so nothing is rounded twice.

Cents are a separate rounding

Rows also carry a legacy credit_amount in rounded cents, and debited_usd_cents rounds half up. The docs treat that as the only rounding in the summary. Do your arithmetic in micros and round once at the end, as the post on sub-cent rows explains.