Money Shorthand Parser

The bug, exactly

```
String(v).replace(/[^0-9.]/g, "")   →   "$25M" becomes "25"   →   25
```

Twenty-five dollars, where twenty-five million belonged. Nothing surfaced the loss. The form saved. The toast said "Saved." The detail page rendered `$25` and looked entirely normal, because $25 is a plausible number.

A strip-non-digits sanitizer does not fail — it succeeds at the wrong thing. That is why it survives code review and ships.

The rules, each a shape that sanitizer got wrong

Suffixes carry magnitude. Dropping `M` is a 1,000,000× error that looks like a small number. An *unrecognised* suffix is refused rather than ignored — ignoring it is the original bug.

Not every number is money. `25x` is a multiple. `13%` is a percentage. Returning 25 for either is worse than returning nothing, because nothing is visible. Checked BEFORE stripping, because once the suffix is gone `25x` and `$25` are indistinguishable. Multiples and percentages get their own parsers and their own units — percentages return basis points, so one can never be assigned to a money field.

Ambiguous input refuses. `1.2.3` is not 1.23. A parser that guesses is a parser that silently corrupts.

An empty string is not zero. `""` means "not entered". Coercing it to 0 fabricates a data point: a company with no disclosed valuation becomes one valued at nothing. The result type distinguishes "left blank" from "could not read" — those need different UI, and conflating them is how bad data gets saved quietly.

Integer minor units, exactly. Not `Math.round(value * 100)`: 1.005 is 1.00499… in binary, so that rounds to 100 cents instead of 101 and the precision claim becomes approximately true. Decimal-to-cents shifts the point textually and is exact for anything a human can type.

Found while building it

Two real bugs in the first draft. `/[~≈about ]/` looks like it matches the word "about" — it is a character class, stripping `a`, `b`, `o`, `u`, `t` individually, so `"1bn"` lost its `b`. And the float rounding above.

Then a mutation survived, which was more useful than the ones that failed: a comment claimed the magnitude table's ordering was load-bearing. It is not — the patterns are anchored, so `mm` can never partially match `m`. The comment was wrong, the anchoring is the real protection, and there is now a test pinning it.

34 tests passing · typecheck clean · 6 deliberate defects applied to the real source — 5 caught, 1 proved unreachable (the range guard can never fire, because decimalToCents already refuses anything past Number.MAX_SAFE_INTEGER); the set and that proof ship in mutations.json, and the survivor corrected a false claim in the source.

Delivery

Private repository invite within 24 hours. Single-product commercial license: use and modify in any number of products; no redistribution or resale of the source.

Interface

What you call, and what comes back. Types and signatures only — the implementation ships with the source.

  export function parseMoney(raw: unknown): ParseResult;
  export function parsePercent(raw: unknown, opts: { max?: number } = {}): PercentResult;
  export function parseMultiple(raw: unknown): MultipleResult;
  export function formatMoney(cents: Cents, opts: { compact?: boolean } = {}): string;

  export type Cents = number;
  export type ParseResult = | { ok: true;
  export type PercentResult = | { ok: true;
  export type MultipleResult = | { ok: true;