Back to all articles

Operations · Guide

After the AI quote, the amount still needs a unit contract

Eight review questions separate currency, precision, rounding, and interface values.

After the AI quote, the amount still needs a unit contract

Original AAHouse explanatory video. AI-assisted conceptual visuals and neural narration; original music.

Simplified Chinese Mandarin transcript · English transcript · Taiwan Mandarin transcript · Hong Kong Cantonese transcript · Macao Cantonese transcript

Is one number enough?

No. Imagine a U.S. service business using AI to organize draft quotes before an approved amount moves to another system. The number 1250 alone does not identify its currency, unit, or decimal scale. This design Q&A follows representation, not pricing authority, tax policy, or investment decisions. It is a hypothetical software review, not a reported customer incident. No payment is performed, and the examples are not instructions to charge a customer.

Original diagram: approved fictional quote → amount, currency, scale → destination adapter; no actual payment controls.

Can we just multiply by one hundred?

Not as a universal rule. Stripe documents amounts in minor units: ten U.S. dollars maps to 1000, while ten Japanese yen maps to 10.[1] This describes representation, not an exchange rate. Put both examples in the adapter tests to expose a hard-coded multiply-by-one-hundred assumption. Check the particular operation, supported currency, and limits separately. A value that is correctly encoded is not automatically an allowed transaction.

Original comparison table explicitly labeled representation examples: USD 10.00 → 1000; JPY 10 → 10; not FX and not executed.

Does a numeric field settle precision?

Check the type and scale. PostgreSQL distinguishes exact numeric values from inexact floating-point types, and a declared scale can round an incoming value.[2] Our recommendation is to define input and calculation precision before choosing storage. Displaying two decimal places does not establish that an intermediate calculation preserved precision. An integer-minor-unit field can suit a bounded interface, while fractional intermediate calculations still need an explicit representation and conversion rule. Also specify the supported range at every boundary; a value may fit one system but exceed another’s limits.

Original layered diagram: accepted precision → calculation representation → storage scale → display; highlight rounding boundary.

When should rounding happen?

The business rule should answer that question explicitly. Rounding each line before adding can differ from rounding a total afterward. Do not let a model or an incidental database default select the policy. Record the rounding mode, the stage where it applies, and the rule version. Where tax or contractual requirements determine the answer, ask the responsible specialist. This article proposes a software control, not the appropriate commercial or legal rounding policy.

Original fork: line rounding then sum versus sum then rounding; label possible difference, no mandated policy.

Does a new symbol convert the amount?

No. Treat presentation and currency conversion as separate operations. Replacing a dollar symbol with a yen symbol changes the reader’s interpretation without supplying an exchange-rate basis. If conversion is actually part of the authorized workflow, record its approved rate source, timestamp, and resulting amount as a separate step. Otherwise retain the original currency and expose the unresolved choice. A localized interface should never silently redefine the commercial value it displays.

Original split diagram: format same amount / separately authorized currency conversion; no exchange-rate numbers.

Can AI fill in a missing currency?

It can surface clues, but should not silently resolve the missing business fact. We recommend blocking an unknown currency, unexpected precision, or unsupported operation until the owner resolves it. Keep the source text, normalized amount, and interface integer traceable to one another. The review screen should show a readable amount with its currency, not only a technical integer or an ambiguous symbol. A structurally valid response from a model is not enough evidence. Preserve corrections and their reasons, so a display-only change cannot conceal a different interface value.

Original gate diagram: missing currency / excess precision / unsupported operation → review; validated tuple continues.

What should acceptance compare?

Compare the complete path, not only a screenshot. Use invented values covering two-decimal and zero-decimal currencies, rounding boundaries, zero, permitted negative values, and out-of-range input. Verify parsing, calculations, storage, interface encoding, and final display. Write the expected pass or block outcome before execution. Run these checks in an isolated test environment without creating real charges. This article describes a test plan; it does not claim the target integration has passed it.

Original test matrix: input/normalized/stored/API/display with cases USD,JPY,boundary,invalid; expected not passed labels.

What should the team keep?

Keep a compact amount contract naming field meaning, allowed currencies, precision, rounding rule, destination interface, and exception owner. Maintain its fixtures with the adapter and rerun them after interface or policy changes. The outcome is an explainable path from the approved business amount to the system parameter. Fewer reconciliation surprises are a goal to measure later, not a result this hypothetical walkthrough claims to have achieved.

Original amount contract card with six fields and regression fixtures attached; no invented metrics.

Need help turning an idea into a pilot?

Discuss your workflow

Sources and further reading

Editorial approach

AI-assisted original writing, checked against linked public sources. Practical recommendations and illustrative scenarios are editorial analysis, not reported client results. Source dates and product details may differ from this collection’s preparation date.