A city treasury office extracts payment amounts from vendor remittance letters into a structured record. With the amount declared as a string, the model returns values such as '$12,400.00', 'USD 12400', and '12,400', and the ledger import fails or misreads them. What is the correct schema-level fix?

Types are the strongest constraint an output contract offers, because a type makes an entire class of malformed values unrepresentable rather than merely discouraged. The treasury office is seeing three spellings of the same payment because a string field genuinely permits all three, and no amount of instruction changes what the contract allows a value to be.

Declaring the amount as a numeric-typed field means currency symbols and thousands separators cannot appear in the value at all. What arrives is ready for arithmetic and for the ledger import, with no parsing step forced to guess whether a comma is a thousands separator or a decimal mark. If the currency itself matters, it belongs in a separate enum-constrained field so each value carries exactly one kind of information.

A regular expression stated in the prompt is guidance the model may miss on any sample, and it still yields a string the importer has to parse; normalizing inside the import job is recurring cleanup that must anticipate every variant vendors and the model can produce; and returning the amount in words makes the value dramatically harder to parse while adding ambiguity rather than removing it.

Exam caveat: floating-point numbers are a poor fit for money, so a numeric field solves formatting but can introduce rounding, and many ledgers prefer integer minor units or a strictly formatted decimal. Operational check: extract a batch of remittance letters, assert every amount is numeric, and reconcile the summed total against the vendor statements to catch rounding drift.