Mustangproject · XML-Import · Help

Mustang invoice import aborts with NumberFormatException

Locate the exact numeric field and separate XML formatting errors from overly strict importer handling.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

A NumberFormatException shows that import processing failed to parse a number; it does not by itself prove invalid invoice XML. Locate the first affected field, its XML path and unchanged raw value, then compare schema validation with parser behavior. Correct localized numbers at the appropriate data source. Do not globally replace commas or substitute zero for required values; a completed import must still preserve correct amounts.

Source basis: Q1 · Q2

Applies to
Covers an archived Mustang import report and XML Schema decimal values. Schema normalization and parser behavior can differ; the available evidence does not verify a released fix.
How to verify the result
The original problem case and valid comparison files produce the expected amounts, while failures remain visibly separated rather than becoming silent zeros or duplicate records.
Your first check

Which field and unchanged raw value trigger the exception?

Preserve the first stack trace and XML location. Do not replace invalid amounts with zero or global character substitutions merely to let the import continue.

Invoice import stops with NumberFormatException, even though most fields look plausible. An archived Mustang report describes one rejected decimal value aborting the whole import, with examples including additional whitespace and locale-formatted numbers. Q1 Map the exception to a particular XML location before attempting a correction.

Separate display formatting from the datatype

A human-formatted number such as 1.234,56 is not the same character sequence as the technical decimal value 1234.56. XML Schema defines decimal notation using a period and no attached unit. Q2 Nevertheless, a parser exception does not automatically establish that the business amount is wrong: an importer can handle whitespace differently from a preceding schema-validation layer.

Find the failing field

  1. Preserve the unchanged input. Keep the file, hash, importer version and first exception. Before repeating an import, determine whether any earlier stage already created records. Retrying must not unintentionally create duplicate processing.
  2. Locate the exact value. Use the stack trace and importer diagnostics to identify the XML path and raw string. Record the affected line item and numeric field rather than merely saying “incorrect amount”. Redact unrelated invoice information.
  3. Compare schema and business value separately. Validate the original XML against the intended schema and rules. If it passes but import fails, differing parser behaviour is significant evidence. If the schema already rejects it, correct the source export first.
  4. Trace the format conversion. Check whether grouping separators, decimal commas, non-breaking spaces or a unit were copied from a display field into numeric XML. Global replacement can alter other fields or change the value. Apply the known datatype and source-system formatting rules instead.
  5. Isolate the failure visibly. Retain the affected document in a review state with its location and error. Do not silently import an unresolved mandatory amount as zero. Continuing other documents requires explicit identity tracking and protection against duplicate processing.

Correct the appropriate layer

Test the repaired exporter or importer with the original failing case and representative valid decimal values. Then compare imported amounts with the source invoice. Removing the exception is not sufficient evidence that the data was transferred correctly.

For handoff, a minimal XML excerpt, raw value, path, stack trace and version details are usually enough. This guide concerns technical data processing rather than approval of the substantive invoice amounts. Preserve the original raw value in the investigation record so that an apparently helpful normalisation can be checked later.

Frequently asked questions

Can I replace every comma with a period?

No. Without knowing the source format, grouping separators and decimal places can be interpreted incorrectly.

Should the importer use zero whenever parsing fails?

Not for an unresolved invoice amount. A visible review status preserves the fact that the value was not reliably imported.

Describe your case

Support with this issue

We can review numeric formats, importer failures and traceable handling of affected invoices.

Describe your case →Related service: Data & improvements

Sources