Invoice vs Credit Note: Why the Document Type Matters

An ordinary invoice records a charge for a supply, while a credit note serves a credit-related adjustment in the applicable invoicing process. The right document depends on what happened and the relevant requirements, not simply whether the amount you want to display is positive or negative. Confirm the correction or adjustment process before preparing a final document.

The document identity and type workflow separates that decision from data entry. EInvoiceCreator currently prepares ordinary positive invoices and does not implement credit notes or issued-document correction status. This distinction remains important even when the same customer and item names appear in both tasks.

Identify the business event

Establish whether you are billing a new supply, correcting an error, recording returned goods or handling another adjustment. Retain the original agreement and any invoice already issued. Those records help an appropriate adviser or supporting system identify the relevant process.

Do not assume that every change requires the same document or that every credit-related event can be handled by editing an existing PDF. The applicable legal, accounting and recipient rules can affect how the adjustment should be represented and linked to the original transaction.

For a fictional supplier, two returned units from an earlier sale are different from a new order for two units. The descriptions and unit prices may look similar, but the intended financial effect and document relationship differ. Establish that meaning before choosing a type or sign convention.

Preserve the original relationship

Where the process requires a reference to the original invoice, keep its actual identity and the information being amended. Do not replace the original number in your records with the new working document’s reference. The relationship needs to remain traceable.

The European Commission’s VAT invoicing overview identifies clear original-invoice reference information for relevant corrective documents within its scope. Use the applicable rules for the actual transaction rather than treating a general article or software label as a universal correction instruction.

If several original invoices or partial adjustments are involved, check whether the final software can represent that structure. The current creator does not maintain those linked document records. A note containing an old reference is not proof that the required structured relationship has been generated.

Distinguish type, structure and amounts

A final format can use different document structures and type fields for invoices and credit notes. OpenPeppol’s published credit-note binding, for example, documents a credit-note type field and profile rules. Changing a heading in an ordinary invoice preview does not implement that binding.

The negative-price and credit-note explanation addresses why a minus sign is not enough. Amount conventions must be checked in the relevant specification, including how quantities, taxes, totals and document meaning fit together. A number that produces a desired arithmetic result may still represent the wrong message.

Do not assume that changing an internal JSON property or file extension adds support. The current application model and exporter must actually implement the relevant structure and validation before the result can be described as a supported credit note.

Review a partial-adjustment example

Suppose a fictional original sale included ten units at EUR 50 before tax, and two units are later involved in a confirmed adjustment. The EUR 100 arithmetic helps quantify the relevant portion. It does not determine the permitted correction method, the correct tax handling or the sign convention required by a particular final format.

Keep the original invoice, affected items, quantities, approved reason and relevant dates together in the preparation records. Do not invent a new ordinary positive sale to imitate the reduction or reduce unrelated future prices simply to create a desired balance.

Where the facts are unclear, obtain appropriate advice and recipient clarification. The browser editor cannot resolve disputes, authorise returns or decide whether an original invoice should be replaced, credited or otherwise corrected.

Choose software that supports the actual task

A supporting system needs to implement the document type, relevant references, amount rules and validation for the intended output. Ask what it produces, rather than relying on a label or an editable heading. Test with fictional data and inspect the result before using sensitive real records.

EInvoiceCreator currently accepts positive quantities and non-negative line prices. It does not offer a credit-note mode, negative-amount workflow or complete advance-payment reconciliation. A required-field pass for an ordinary invoice should not be presented as a validation of an unsupported adjustment.

Printable output, application JSON and line-items CSV retain their stated preparation purposes. None becomes a recognised credit-note representation simply because a user discusses a correction in the notes field.

Keep evidence and status clear

Identify the original document, confirmed adjustment, new working version and any remaining external task. Preserve issued records according to the relevant process rather than overwriting them silently. The current product is not an authoritative ledger or correction-history service.

After a suitable generator produces the required document, review the actual file and relevant validation or delivery evidence. Technical validity and recipient business acceptance remain different questions. Clear preparation makes that next stage possible without pretending that a local ordinary-invoice editor has already completed it.