ecko
The problem
Three-way match compares PO, receipt, and invoice lines. Amounts look equal until 0.1 + 0.2 != 0.3 shows up on a ten-million-row ledger and the ERP will not post.
Teams bolt on Decimal libraries in Python or use integers in cents, but JSON from OCR and LLM extraction still arrives as floats unless something enforces decimal at the boundary.
Why Ecko
- Decimal literals
- Write
19.99mand arithmetic stays exact. No string parsing step, no "multiply by 100 and hope" convention scattered through the codebase. - Typed line items
- Extract invoice rows into structs with
decimalfields. A model that returns19.9900001fails validation instead of silently reconciling. - The money package
- ISO 4217 minor units, allocation that never loses a cent, and currency-safe operations when you outgrow bare decimals.
In practice
type Line = { sku: str, qty: int, unit_price: decimal }
fn total(lines: list(Line)) -> decimal {
mut sum = 0m
for ln in lines { sum = sum + ln.unit_price * decimal(ln.qty) }
sum
}
Try it on your workload.