A Core Invoice Usage Specification, often shortened to CIUS, narrows how a core invoice model is used for a particular context. For a creator or mapper, that means a generally available field or value may need more specific handling. Supporting the broad model is not automatically support for every CIUS.
The mapping preparation workflow records the actual target specification before implementation. The current creator has no verified CIUS adapter or formal standards validation. Its country context does not supply the national usage rules a recipient may require.
Identify the actual usage specification
Ask the recipient which specification and release it uses, together with the intended syntax and delivery process. Do not infer the answer solely from the customer’s country or a broad request for EN 16931.
KoSIT describes XRechnung through a CIUS and extension context. That provides a concrete example of a national specification built around the European model, but the exact scope must be read from its applicable documentation. Do not use the example as a universal rule for every invoice destination.
Record production status and source. A future draft, older archived release and current recipient requirement can all be available on official websites. The mapper needs to know which one controls the actual output.
Review tighter requirements
A usage specification can further constrain fields, values or relationships within its defined scope. Confirm the exact restrictions instead of assuming every optional part of a broader syntax remains optional for the receiver.
Read the field definitions and conditional rules together. A value may be permitted structurally but inappropriate under the required business context. The implementation needs the relevant rule set, not only a general schema.
Do not invent missing facts to satisfy a tighter requirement. A plausible endpoint or buyer reference is not a substitute for the actual value. Collect the confirmed source data or report the unresolved gap before final export.
Compare the source model
Make a requirement table showing the target role, source value, transformation and known limitation. The current creator may lack dedicated identifiers, schemes, line periods or formal tax structures needed by the usage specification.
A text note can preserve a reminder for a person but does not create the missing typed field. If another system finalises the invoice, give it the components and meanings separately rather than expecting it to infer them from prose.
Keep commercial and tax determinations outside mechanical mapping. A profile requirement for a category or reason does not decide which treatment applies. The mapper expresses confirmed facts according to the specification; it does not establish their real-world basis.
Distinguish restrictions from extra content
Do not assume that adding more data always improves compatibility. A restricted profile may not permit every feature of the broader syntax. Extra elements or conflicting declarations can create failures even when the additional text seems helpful to a reader.
Likewise, an extension has its own scope and cannot be assumed acceptable merely because it accompanies a familiar core model. Confirm what the recipient and implemented exporter support. Keep optional future ambitions separate from the production requirement.
Use the code-list review where values are constrained. A broad list’s valid value can still be outside the permitted subset. The implementation needs the field context and actual allowed set.
Test the required context
Use fictional examples covering the restrictions relevant to the real transaction. Include a missing conditionally required value and a code permitted broadly but not in the chosen profile where applicable. Inspect the actual validator result rather than assuming a broad test covers it.
Retain the specification, mapper and validation configuration with the exact generated file. A report about another profile or earlier release is not evidence of the current target. Repeat affected cases when rules or source mappings change.
Review semantic accuracy too. A profile-valid identifier can still belong to the wrong buyer, and a correct-looking amount can come from the wrong quantity. Automated restrictions do not replace source-fact review.
Keep capability claims specific
A provider should state which usage specification, version and scenarios it implements and which checks it performs. Avoid broad assurances such as all European invoices supported without evidence of the actual combinations.
The creator’s current application JSON, CSV and printable output remain preparation outputs. They do not become XRechnung or another CIUS implementation when a country is selected or the specification name appears in notes.
Before delivery, resolve source gaps and use a final system that genuinely implements the required context. The useful result is a mapping record and tested output matched to this receiver, with legal determination, transmission and acceptance treated as separate responsibilities rather than inferred from a broad standards label.
A practical provider enquiry asks which CIUS release is implemented, which restrictions are tested and which scenarios remain unsupported. Keep the answer with a representative fictional file. If the provider supplies only a broad syntax claim, mark the CIUS requirement unresolved until the actual implementation and evidence are identified.
Confirm the accepted production release with the actual receiver.