Identify a model gap by comparing a required business fact or behaviour with what the application actually represents. A value written somewhere in notes is not necessarily a supported typed field. A calculation forced through an unrelated control is not implementation of the required financial relationship.
The mapping preparation workflow records these gaps before final export. The current creator supports useful browser-local preparation, but its application model is narrower than many formal invoice profiles. Educational coverage does not change that implemented scope.
Start from an exact target
Record the recipient’s specification, profile, syntax and version. A gap assessment is meaningful only against a defined requirement. A general wish to support electronic invoices does not identify which business facts and rules must be implemented.
Obtain the applicable field definitions and conditions. Do not infer requirements solely from a sample containing one simple transaction. That file may omit the situation your invoice needs to represent.
Keep the source instruction and production context identifiable. An archived release, future draft or different customer profile can create a misleading gap list if treated as the actual target without confirmation.
Inventory source capabilities honestly
List supported fields and their meanings, precision and relationships. The creator has multiline party addresses, limited reference fields, free-text units and manual tax controls. Those are useful application features, but they do not establish every formal component or code mapping.
Examples of possible gaps include typed endpoint schemes, separate item identifiers, line periods, formal exemption codes and price-base quantities. Check the actual requirement rather than assuming every listed feature is mandatory for every invoice.
Do not mark a fact as represented merely because a person could extract it from a description. A future parser may guess incorrectly. Preserve confirmed components separately for the implemented final mapper.
Separate different kinds of gap
A source-data gap means the fact has not been collected or confirmed. A model gap means the application lacks the necessary role or relationship. An adapter gap means mapping is absent. A validation gap means the required checks are not implemented.
These need different remedies. Adding a text field does not automatically build a standards adapter, and adding an adapter cannot responsibly invent missing source facts. A validator can report problems without determining the correct real-world answer.
Record each gap with its type, impact, owner and completion evidence. Avoid one vague status saying needs compliance. Concrete tasks are easier to implement and review without overstating progress.
Include financial behaviour
Check quantities, price bases, adjustments, tax grouping, currency roles and payable reconciliation. The current creator supports its documented positive-line model, not every formal financial structure. Similar totals can conceal different meanings.
A prior payment cannot be implemented by reducing a unit price without changing the commercial statement. A global allowance cannot be assumed equivalent to a line percentage. Record the required behaviour rather than forcing the current controls to imitate it.
Use the adjustment mapping review to identify these dependencies. Keep the accepted transaction and appropriate determination separate from the choice of technical representation.
Define a safe handoff
Preserve supported source data and additional confirmed facts in a reviewable record. Identify the final system responsible for missing fields, calculations and validation. Do not leave a required stage as an assumption that another person will somehow complete later.
You can prepare supported information locally before that handoff. Its application JSON can retain the documented model for editing, while additional facts may need separate source records. Check the final provider’s actual import contract rather than assuming universal compatibility.
Do not send real customer files to unfamiliar tools merely to discover their features. Use fictional cases to test the mapping mechanism and privacy-appropriate processes for production data.
Test completion of each gap
A gap is complete only when the required behaviour is implemented and the relevant tests demonstrate it. A new label, roadmap item or badge is not sufficient. Inspect the actual output and its required validation evidence.
For a fictional endpoint gap, collect a demonstration value and scheme separately, map them into the intended target role and test a missing-scheme case. This checks more than whether one new input box accepts text.
For a financial gap, include a representative positive and negative case with reviewed expected results. Keep the source, implementation configuration, generated file and report together. Repeat affected tests after changes.
The creator’s current printable output, JSON and CSV do not establish a formal EN 16931 binding, legal validity or acceptance. A clear capability register preserves useful preparation while making the remaining work concrete enough to implement, verify and communicate accurately.
For a development handoff, define a completion check that can fail. A new field should preserve the intended fact, a new adapter should generate its target role and a new validator should reject a documented invalid case. Requiring this evidence prevents a roadmap feature from being marked complete merely because its label appeared in the interface. Keep these checks separate so an adapter test cannot be substituted for an absent source-data decision.