Invoice prompts: recalculate typed charges

Last updated: 7 Oct 202611 min read

tutorial

An invoice total is computed from typed quantities, prices, discounts, freight, tax, credits, and currency under a declared rounding rule. Let decimal-safe code perform the calculation and ask the model to explain the locked result. Matching the printed total establishes arithmetic only. It does not show that freight was agreed, tax was calculated under the right rule, or goods were accepted. Keep charge types and the exact difference visible instead of returning one unlabeled amount.

Operational case

North Quay's line amount is 47 times 29, or 1,363. The stated freight 64 and stated tax 95.41 sum to a 1,522.41 invoice total, matching the printed figure. That arithmetic is correct. The packet still lacks a verified tax-basis decision and has a receiving gap. The assistant reports those gates separately; it cannot call the invoice approved just because the calculator returned zero difference.

Line: 47 × 29 = 1,363
1,363 + 64 + 95.41 = 1,522.41
Printed total: 1,522.41; arithmetic difference: 0
Tax basis and receipt match: unresolved

Performance and review cost

Summing L lines is O(L) time and O(1) working memory with a running decimal total; a traceable line ledger uses O(L) storage. The calculation is cheap. Correcting a posted misclassification is expensive, so retain every charge and its rule status for review.

Common Mistakes

Do not use binary floating point for final money comparison.
Do not infer tax validity from matching arithmetic.
Do not hide freight inside unit price without a rule.

Connected lessons

prompt engineering

invoice operations