XML Invoice Tool

Why it exists, how it works, and what it intentionally does not do.

Home Run tool
Deterministic processing. No data retention.

Files are processed per job, returned as a ZIP, and temporary data is not retained. No inference, no external systems, no hidden logic.

Why this exists

XML invoice pipelines usually fail for small reasons rather than large ones. The data is mostly correct, but slightly wrong.

Common causes include pricing precision mismatches, invisible whitespace, partial resubmissions, and unsafe filenames.

This tool applies explicit, controlled corrections to address those issues. Nothing is inferred. Nothing is guessed.

How XML invoice validation typically fails

Most XML invoice validation failures are not caused by incorrect business data, but by structural or numerical inconsistencies treated as fatal by validators.

These failures often appear late in the pipeline, after files have already been generated, reviewed, and transmitted.

The result is a rejected batch that must be manually inspected, corrected, and resubmitted under time pressure.

Common validator failure patterns

  • Numeric inconsistency - calculated values do not match declared totals
  • Unexpected whitespace - invisible spaces invalidate schema rules
  • Empty containers - parent elements remain after child removal
  • Filename collisions - resubmitted files overwrite prior uploads

Example validator errors

Numeric validation failure

ERROR: Line total does not equal quantity multiplied by unit price.
Expected 10.00 but calculated 9.99.

Even small rounding differences can cause full batch rejection.

Schema validation failure

ERROR: Element '  SupName  ' is not valid.
Value contains leading or trailing whitespace.

Whitespace is invisible to humans but significant to validators.

Structural validation failure

ERROR: Element 'Surgery' must contain at least one 'Invoice'.

Containers must be removed when all child invoices are deleted.

Detailed per-line change logs may be added in the future once they can be generated deterministically and reviewed safely.

Why controlled fixes matter

Validator failures often force teams to choose between speed and correctness.

Blind regeneration risks introducing new discrepancies. Manual editing risks human error.

This tool applies narrow, explicit corrections that are easy to review, reason about, and repeat.

The goal is not to hide errors, but to remove known failure conditions without altering business intent.

Processing flow

Upload XML
   |
   v
Filter invoices (explicit list only)
   |
   v
Normalize XML (spaces, pricing)
   |
   v
Optional safe rename
   |
   v
Recalculate batch totals
   |
   v
ZIP output

Each step is explicit and deterministic.

What the tool does

  1. Accepts one or more XML invoice files
  2. Keeps only explicitly listed invoices
  3. Normalizes formatting and pricing
  4. Optionally applies safe renaming
  5. Recalculates batch totals
  6. Returns the result as a ZIP

All operations are linear, repeatable, and explicit.

What this tool will not do

  • Infer missing data
  • Modify business logic
  • Silently fix broken source invoices
  • Connect to external systems
  • Persist invoice data

If source data is wrong, it should be corrected at source.

Examples

Whitespace cleanup

Before 
<SupName>  ACME Vets Ltd  </SupName>
After 
<SupName>ACME Vets Ltd</SupName>

Pricing normalization

Before 
<InvoiceLine>
<LineQty>3</LineQty>
<LineUnitPrice>3.33</LineUnitPrice>
<LineValue>10.00</LineValue>
</InvoiceLine>
After 
<InvoiceLine>
<LineQty>3.333333</LineQty>
<LineUnitPrice>3</LineUnitPrice>
<LineValue>10.00</LineValue>
</InvoiceLine>

Quantity and unit price are reconciled so the calculated value matches the line total within accepted precision limits.

The sections below describe operational edge cases handled by the tool.

Partial posting and invoice filtering

In many real-world scenarios, only a subset of invoices in a batch needs to be resubmitted or corrected.

This tool keeps only the invoice numbers explicitly provided in the input text area. All other invoices are removed.

Empty containers are cleaned up automatically and batch totals are recalculated to reflect only the remaining invoices.

This avoids accidental reposting or unintended financial impact.

Filename handling and safe renaming

Incoming files often contain timestamp-based suffixes added by upstream systems or manual exports.

If a trailing timestamp is detected, it is removed automatically to restore the logical base filename.

If renaming is enabled, a predictable alphabetical suffix is appended to avoid collisions during resubmission. 

invoice_20240131.xml  -> invoice.xml
invoice.xml          -> invoicea.xml
invoicea.xml         -> invoiceb.xml

Existing files are never overwritten.

Why this page is separate

Execution and explanation are intentionally separated.

The tool stays fast and focused. This page evolves as functionality grows.