Invoice Type Codes: What a Creator Needs to Know

An invoice type code describes the functional kind of a document under the applicable specification. It is not the invoice’s unique reference, a customer order number or a free-text heading. A final structured generator must use a permitted value and the document structure and business rules that go with the chosen profile.

The document identity and type workflow establishes the business task before final generation. EInvoiceCreator currently prepares ordinary positive invoices and does not provide a recognised-format type-code selection or mapping. This article explains what supporting software may need, not a hidden feature of the current export.

Identify the business document first

Determine whether the transaction needs an ordinary invoice, credit note, correction, prepayment-related document or another supported type. That decision depends on the actual business facts and applicable requirements. Do not choose a code merely because it appears in an online sample or produces fewer validator messages.

A code cannot supply missing facts about what happened. If goods were returned or an issued invoice contains an error, establish the appropriate correction process before choosing the final representation. The current editor cannot decide that process or maintain the status of previously issued documents.

For a fictional supplier, a new sale and an adjustment to an earlier sale are different preparation tasks. They can involve similar item descriptions while requiring different references, amount treatment and document structures.

Read the code list in its profile context

OpenPeppol’s published invoice type subset includes code 380 for a commercial invoice, alongside other document types. Its invoice-type field documentation also identifies profile-related rules. This is an example of a documented list and binding, not a universal instruction to place 380 into every file labelled as an invoice.

Use the actual specification and version the recipient accepts. A broader format’s code list can contain values that a particular profile restricts. A code’s existence in a general list does not establish that your final generator supports it or that the recipient will accept the associated document.

Do not infer support from a field name in an application-owned JSON file. A property labelled “type” can describe an internal application object rather than the invoice business type required by an external semantic model.

Distinguish the code from the document number

The invoice number identifies a particular document in the seller’s records. A type code classifies the functional document. Many invoices can share the same permitted type code while each has its own document identity. The two values should not be substituted for one another.

A customer’s purchase order is another separate reference. It identifies the purchasing record, not the invoice type. Likewise, a payment reference supports reconciliation rather than defining the document’s business meaning.

Keep these labels in the preparation sheet so the person completing the final mapping can interpret the data. An unexplained number copied into a notes field does not establish which role was intended.

Keep structure and calculations aligned

Choosing a document type can affect the final message structure, references and amount conventions. Changing a visible heading while leaving an ordinary invoice model unchanged does not implement those requirements. A PDF that says “credit note” is not proof that the relevant structured credit-note representation exists.

The invoice and credit-note comparison explains why the business type matters beyond presentation. Supporting software must handle the required document family and rules, not simply let a user type a different title above the same amounts.

The current creator accepts positive quantities and non-negative prices. It does not generate credit notes, implement negative-amount documents or perform formal profile validation. Those limitations remain even if someone adds a type-like label to a draft file externally.

Prepare information for a capable generator

Give the supporting system the confirmed transaction purpose, relevant original-document references, parties, items, amounts and recipient profile. Identify any missing fields or unsupported adjustments before attempting final export. Do not distort the facts to fit a convenient code.

If the generator asks for a type you do not understand, consult the specification or appropriate adviser. A dropdown label can be a helpful interface aid, but its presence does not determine the legal or accounting meaning of the transaction.

Before relying on an external generator, test the chosen document type with fictional data and inspect the resulting file. Confirm that the type, original-reference fields and amount conventions appear in the expected structure rather than only in the readable preview.

Keep the final validation report with the generated version where relevant. A valid code value is only one part of a valid message; required references, mapped fields and business rules still need checking. Recipient business acceptance can also involve facts outside the technical validator.

Describe the current output accurately

EInvoiceCreator’s JSON export is structured application data with an explicit indication that standards validation was not performed. Its printable output and line-items CSV serve their stated limited purposes. They should not be described as implemented standard document types merely because the interface discusses those concepts.

A clear preparation record states what the business document is intended to represent and what supporting generation remains. That preserves the meaning of a type-code decision without pretending that editing a label, file extension or internal property creates an implemented standards adapter.