Check decimal strings before loading extracted JSON into numeric code

Choose a representation for the actual task

Check the intended representation before calculation so the processing code does not silently alter a value that extraction preserved correctly.

Before paying for technical-document extraction, inspect how the source meaning survives in the output. ParseMill’s public material-register example gives you a synthetic PDF and downloadable evidence to compare. Bring your own document type and acceptance checks to a scope discussion; the self-service invoice plan is a separate offer.

Do not convert numeric-looking identifiers at all merely because a parser accepts them. A long code and a measured decimal need different treatment even if both contain digits. Record field roles before applying a general conversion function.

Use an executed conversion fixture

During preparation, Python 3.14.6 produced the two arithmetic results shown and the identifier remained text. This is a small representation check, not a benchmark or a claim that one numeric type suits every analysis. Other operations still need the precision and rounding policy required by the task.

Python: Decimal fixed-point and floating-point arithmetic documents decimal construction from strings and arithmetic contexts. Constructing from an already rounded binary float does not recover an original decimal string.

Test the conversion boundary

1. Validate the field’s role and preserve raw text, unit and source reference. Reject or hold ambiguous locale strings and qualified values that do not represent ordinary scalars.
2. Choose a numeric type and explicit rounding policy for the consumer. Record precision, scale and treatment of unsupported values.
3. Test representative inputs including trailing zeros, negative values, small magnitudes and boundary cases relevant to the calculation. Compare against independently specified expected results.
4. Serialize and re-read the derived output, then check both numerical meaning and required presentation. Keep conversion failures linked to their source records.

RFC 8259: JSON data interchange permits implementations to impose numeric range and precision limits. A valid JSON number therefore does not guarantee identical representation in every consuming language or application.

Avoid silent coercion

Replacing an invalid decimal string with zero hides a conversion failure as a measurement. Stripping a less-than sign creates an exact value the source did not supply. Keep these cases as structured exceptions with the raw input intact.

Decide whether equality checks should be exact or use a justified tolerance for the intended computation. Do not add an arbitrary tolerance merely to make a failing test pass, and do not infer measurement uncertainty from floating-point representation effects.

Record the consumer’s actual requirements

The fixture demonstrates why raw text and analysis numbers need separate checks. Acceptance for a real pipeline includes its own arithmetic, rounding and serialization tests, with unsupported cases remaining explicit. Save the chosen policy with the derived output version.

Bring this decimal fixture and the consumer’s precision requirements to a scoped integration discussion. Agree the input representation, rounding policy and acceptance checks before a pilot. ParseMill’s self-service invoice workspace delivers an Excel workbook; a general JSON pipeline needs separate scope.