Before converting an invoice, check that the source contains the target’s required facts and that the converter preserves their meanings. A conversion is more than changing an extension or rearranging text. It needs an implemented mapping, clear handling of unsupported data and validation appropriate to the destination.
The format-selection workflow establishes the target first. The current creator’s application JSON, line-item CSV and printable output have different scopes. None should be assumed to contain every fact a recognised e-invoice format requires.
Identify the source contract
Record what the input actually contains and which model defines it. A line-item CSV lacks the complete document context of a full invoice model. A PDF may require extraction before facts can be mapped, while the creator’s JSON has its own documented field meanings.
Do not infer meanings from short labels alone. A field called reference may identify a buyer routing instruction, purchase order or payment matching value. A converter must know the intended role, not just copy the string into the first compatible target field.
Keep the actual source version and supported precision visible. If a price was rounded before export, a converter cannot reconstruct the original agreed rate reliably from the final line amount. Lost input precision is different from a new target rounding policy.
Define the target requirement
Obtain the recipient’s exact format, profile, version and route. Record required identifiers, code lists, conditional fields and financial relationships. A broad request for XML is not a complete conversion specification.
Compare every required fact with the source. If the source lacks a typed endpoint, exemption code or line period, obtain the confirmed value separately. A converter should not invent it merely to satisfy a mandatory field.
A useful gap table contains source fact, target role, transformation, unsupported condition and owner. Keep genuine gaps visible. A successful output file that silently omits essential facts is not a satisfactory conversion.
Review calculations and adjustments
Compare quantity, unit and price bases, discount representation and tax calculation sequence. Different models can use different adjustment levels or rounding stages. A matching final total does not establish that the underlying financial meaning was preserved.
The current creator supports positive invoices with percentage line discounts and its documented fixed-point sequence. It does not implement document allowances, prepaid reconciliation or other account adjustments. A target requiring those features needs a suitable final model.
Do not compensate for a mapping gap by altering commercial quantities or tax categories. Resolve the representation from the accepted transaction and applicable requirements. Otherwise the converter may produce a technically neat document that describes a changed sale.
Inspect code and identifier handling
Ask how the converter maps source labels to formal codes and preserves identifier schemes. A free-text unit label is not automatically a validated unit code. An email address does not automatically identify the intended electronic endpoint role.
Keep values and their roles separately in the preparation record. Review leading characters and significant formatting. Spreadsheet or extraction tools can reinterpret identifiers as numbers, so compare the actual mapped values rather than only their rendered appearance.
Use the profile check to identify restrictions beyond the broad syntax. A target schema may permit values that the receiver’s profile disallows. The conversion test needs the relevant rule sets, not only a generic parser result.
Test representative cases
Use fictional data containing the kinds of lines, references and treatment conditions the real workflow needs. Include missing required information, unsupported precision and deliberately different reference roles. Check that the converter reports problems rather than silently defaulting them.
Compare source and target field by field, including readable output where relevant. For a hybrid, review the relationship between the visible page and embedded invoice data. A screenshot of the page does not prove the payload is correct.
Retain the exact source, target and configuration with the test result. A later converter release or changed profile may need repeat testing. A report about one simple example is not evidence that every conditional scenario is implemented.
Protect data and complete the handoff
Determine how any external converter processes and retains invoice contents before sending real customer information. The creator’s local processing does not authorise an unrelated third-party upload. Use fictional records for capability testing where practical.
After mapping, run the required validation and assign delivery separately. Conversion success does not establish tax correctness, legal validity, transmission or recipient acceptance. Keep the evidence for each stage identifiable.
A final review should show which meanings were preserved, which transformations were justified and how unsupported requirements were resolved. If those answers are missing, do not rely on a reassuring converted filename. Use an implemented final workflow that can produce and check the actual document the customer requested.
For an acceptance checklist, trace at least one party identifier, date, line quantity, tax reason and payment reference from source to target. Record the intended role beside the copied value. This exposes mappings that preserve characters but exchange meanings. Include a missing-field case too, so you can assess whether the converter fails clearly rather than silently fabricating data.