Issued invoices

The Issued invoices screen is the last step of the sales chain: after the quote and the order, you invoice what has been carried out.

Issuing an invoice is not the mirror of receiving a supplier invoice. Receiving means reading a file produced by a supplier and checking it against the order. Issuing means producing a legal act: the document commits you, its number is regulated, and once issued it can neither be edited nor deleted.

Two stages: the draft, then issuance

An invoice starts as a draft. At that point it is freely editable and deletable, and it has no number yet. That is intentional: invoice numbering is continuous and without gaps, so the number is only assigned at issuance — an abandoned draft must not leave a gap in the sequence.

Creating a draft happens two ways:

• Invoice an order — the common case. You pick a completed order for the customer, and its lines are carried over as they are, with its references. Nothing to re-enter, and the link lets you track what remains to be invoiced on the order.
• Free lines — for an invoice with no order behind it.

Issuance

The “Issue invoice” button crosses the point of no return. In a single operation it:

1. assigns the legal number — FV-2026-00001, continuous and specific to each fiscal year (the sequence restarts at 1 each year);
2. freezes the amounts — they will not change, even if a calculation rule evolves one day;
3. produces the electronic file — the CII (the structured XML format admitted by the reform), archived as evidence and downloadable from the detail view.

Issuance is irreversible. An issued invoice can no longer be edited or deleted. An error is corrected by a credit note — a corrective invoice linked to the original (see below).

Transmit and follow the life cycle

Once issued, the invoice — like the credit note — follows its regulatory life cycle, from the issuer’s point of view:

Before transmitting an invoice destined for a public buyer, Envergure checks the completeness of the Chorus Pro references (customer SIRET, executing service code, commitment number): if one is missing, transmission is blocked rather than suffering a rejection and seeing the payment deadline restart from zero. A private B2B invoice, without those references, passes unchecked.

Invoicing a public body

As with the order, an invoice destined for the public sector goes through Chorus Pro and requires three routing references: the customer SIRET, the executing service code and the commitment number. They are carried over from the order — that is where they were captured, the public buyer having provided them at that time.

If they are missing on a draft, an alert banner flags it before issuance: an incomplete public invoice would be rejected, and the payment deadline would restart from zero.

Correcting an invoice: the credit note

An issued invoice is not crossed out. When you must revisit it — cancellation, discount, wrong quantity or price — you issue a credit note (a corrective invoice). It is a document in its own right, of the same kind as an invoice, but negative to invoicing: it corrects a specific invoice.

From an issued invoice’s detail view, “Create credit note” opens a credit-note draft that carries over the invoice’s lines. Two uses:

• Full credit note — issue the draft as is: it cancels the whole invoice.
• Partial credit note — adjust the draft first (lower quantities, remove lines) to correct only part of it, then issue it.

The credit note has its own numbering, a series distinct from invoices: AV-2026-00001, also continuous and per fiscal year. On issuance, it reverses the invoicing: what it corrects becomes “to invoice” again on the original order. Its electronic file carries type code 381 (credit note) instead of 380 (invoice) and recalls the number of the corrected invoice.

A credit note is only created on an issued invoice — never on a draft (corrected directly) nor on another credit note.

What this “electronic” format is, concretely

The CII file contains, in structured XML: your legal issuer identity (set in the

instance settings), the customer’s, the line detail, the VAT breakdown by rate and the totals. This is the file the platform and the administration can read automatically — where a plain PDF would have to be re-keyed by hand.

Two formats to download: the CII and the Factur-X

From an issued invoice, two buttons:

• Download the CII — the XML alone. It is the authoritative artifact, the format the platform reads mechanically.
• Factur-X (PDF) — a human-readable PDF (a classic invoice layout) that embeds that same CII as an attachment. A recipient opens it like a normal invoice; their software extracts the XML from it. One file, two readings.

Both come from the same data: the PDF invents nothing, it dresses up the CII.

Assumed limitation: the Factur-X produced is a valid PDF that embeds the XML correctly (we verify it by reading it back with our own reception extractor). Strict conformance to the PDF/A-3 archival profile (colour profile, fully embedded fonts) requires a tooled validator, which we will confront the day a recipient requires it.

Restitution to the financial ERP

Issued invoices (and credit notes) are exported to the financial ERP to hold the receivables, just as supplier invoices are for the payables. The export is self-contained — codes and identities in clear, the ERP needn’t know our internal IDs — and provides control totals the accountant reconciles against their entries. A signed total counts credit notes as negative (the net receivable). Drafts are excluded: only an issued invoice is a receivable.

What this screen does not do (yet)

• Transmission is not yet a real network send to Chorus Pro. The life cycle and completeness check are in place; in file mode, “transmit” declares that you have deposited the CII. The actual platform hookup (automatic send) will come once its official specification has been checked — the rest of the chain will not change then.
• It handles neither dunning nor accounting — cashing is only recorded here (from the financial ERP), the rest is the ERP’s job.