E-Invoicing
The E-Invoicing screen is the central operational page of NomaUBL — the official entry point for the Réforme de la Facturation Électronique (RFE) workflow. It lists every invoice the platform has processed, with rich filters, a status-driven detail view, and the actions a user needs day to day: edit, copy, delete, manually set a status, e-mail the PDF to the customer, resend to the Plateforme Agréée.
The page applies regardless of source system — JD Edwards, SAP, NetSuite or a custom ERP. Every record visible here was persisted in the local NomaUBL database after going through the processing pipeline.
At a glance
Toolbar
Above the grid, two rows: the period, the direction, Exclude reviewed errors and, at the right, + New Invoice; then the status by stage. + New Invoice is shown to the roles allowed to create invoices (invoice.create), which opens the Create / Edit invoice modal. The Advanced Filters panel and the grid toolbar (search, Run, bulk actions) follow.
Period
The shared period picker: presets, two-month calendar, and the date basis in its footer. The list opens on This month, or on the default period set for the Invoices view. A list opened from a dashboard or a VAT drill-down takes the dates of that page.
Date basis
The footer of the period picker chooses which date column the period is read against.
| Value | Date column | When to use |
|---|---|---|
| Update date (default) | The last time the invoice was modified in NomaUBL. | Day-to-day operations. |
| Issue date | The date printed on the invoice itself (BT-2 from the UBL). | Reconciling against the VAT Declaration page or any external system that keys off the issue date. |
| Archive date | The date the document was processed into the archive. | Reconciling against the IT dashboard and the processing reports. |
The choice is remembered for the current session. It is also set automatically when the list is opened from a dashboard or a VAT drill-down, so the count on E-Invoicing matches the count you came from.
Direction
A selector next to the period: Issued (sales) (default), Received (purchases), or All directions.
| Value | Effect |
|---|---|
| Issued (sales) | Only the invoices sent to customers (UHDRIN = '2'). |
| Received (purchases) | Only the supplier invoices pulled from the PA (see Sync → Fetch Input → PA inbound and the bundled received-ubl document). |
| All directions | No direction filter — both are listed. |
The selector resolves against the UHDRIN flag stored on each row — a template's Direction change does not re-classify historical rows, so the result is stable over time.
On a Received row the Counterparty column reads from AccountingSupplierParty (the supplier), not from AccountingCustomerParty — so the column shows the supplier name on inbound invoices and the customer name on outbound ones. The status workflow, the detail modal and the column catalog are otherwise identical; only the emit-only seller actions (Resend to PA, Send completed, Credit note…) are hidden on received-direction rows.
Exclude reviewed errors
The Exclude reviewed errors switch, next to the direction selector, hides the rows already marked Reviewed that still sit in an error status (errorTech / errorBusiness groups of the statuses template), so the list keeps only the errors nobody has looked at yet. Reviewed rows in any other status stay listed. The switch is on by default; a list opened from a dashboard (Billing overview, Statistics, Operations) takes the dashboard's choice. The GET /api/invoices endpoint takes the same filter as excludeReviewedErrors=true.
Status by stage
The Status row groups the statuses of the period into the five stages of the Statistics dashboard — To correct, Decision needed, Processing, At the platform, Completed — plus Other when a status outside these groups has invoices or is selected. Each stage is a pill with its colour and count.
| Gesture | Effect |
|---|---|
| Click on the stage name | Selects every status of the stage (Show only this stage); a second click shows every status again. |
| Click on the caret ▾ | Opens Choose statuses: a checkbox for the whole stage (all, none or partial) and one per status, with its colour, label and count, biggest first. |
| Partial selection | The count reads picked / total and the pill gets a dashed border. |
| ✕ Clear filters | Appears when a status is selected; clears the selection. |
A stage with no invoice on the period is greyed out. A dashboard click (a queue, a stage, a status) lands on the list with the matching statuses already picked.
Advanced Filters
A collapsible Advanced Filters panel sits below the status row. It offers one row per filterable column of the active List Views spec — by default DOC, DCT, Company, Party Number, Party Name, Bar code, Review, Status, Invoice type, Activity code, Reason code — with a per-column operator picker (contains, equals, ≠, <, ≤, >, ≥, between, empty, not empty). Edits stay as a draft until Run commits them, so typing in the panel does not spam the back-end.
A text filter matches from the start of the value and uses the column's index, so the list stays fast on a large table. To search for text anywhere in the value, wrap it in percent signs — %acme% matches acme wherever it appears, at the cost of a full scan. The DOC filter takes a shortcut: an all-digits value seeks the document number directly rather than scanning. Filters on columns backed by a reference list (status, routing…) accept several values at once — pick more than one and the list shows rows matching any of them.
The set of columns that can be filtered is defined in the spec's filter: true allow-list — operators decide which columns they actually query and trim the rest from the panel without losing them from the grid. See List Views for the editor.
The page runs in hybrid client-side mode: each Run loads one capped slice from the server (spec.maxRows, the Rows loaded of Settings › Navigation & lists unless the view sets its own — 100 000 by default) and the grid handles filter / sort / paginate / group within that slice — no roundtrip while typing in the per-column filter row, filters survive pagination naturally. When the slice cap is hit, an X / Y rows notice next to Run tells the operator to narrow the period or the Advanced Filters.
RefList columns (Status, eReporting Status, custom lists) get a multi-select picker in both the Advanced Filters panel and the per-column filter row — pick any number of codes, the trigger shows N selected past the inline cap, and a ✕ on the right resets the selection in one click. The server applies an IN (?,?,?) clause so picking three statuses returns the union. A code can also be typed in the search box of the picker (Enter, comma-separated for several), so a list that is incomplete or still empty still filters.
Grid toolbar
Next to the search box of the grid: Run (reloads the list with the current filters), then Resend selected (N), Reprocess selected (N) and Mark reviewed (N) when rows are ticked (see Bulk resend, Reprocess and Mark reviewed). The view picker saves and brings back the display of the list — columns, widths, sort, filters, period: see Saved views.
Invoice list
The table shows one row per invoice. Default sort: most recent document number first. Click any column header to sort by that column.
The grid renders through DataTableV2 in spec-driven mode: column shape, labels, format, alignment, width and the filter-row allow-list come from the view.invoices spec stored on db-nomaubl (with a bundled default in the JAR). Adding or removing columns is done from the List Views editor — no code change required when the column already lives in the catalog.
The Updated value carries the time of day, so an Updated column formatted as datetime in the spec shows 2026-09-15 15:23:45 rather than the bare date. (The issue date stays date-only — JDE stores no time for it.)
Default columns
| Column | Description |
|---|---|
| Doc | Internal document number. |
| Dct | Document type. |
| Kco | Company code. |
| UBL number | The invoice number as it appears in the generated UBL document. Filterable from the Advanced Filters panel and via the ?ublNumber= query parameter, on top of the free-text search box. |
| Issue date | BT-2 from the UBL. |
| Customer | Buyer party name. |
| Country | ISO 3166 two-letter code of the counterparty (FR, DE, BE, US…). Captured at insert from the UBL — buyer country on sales, supplier country on purchases. Drives the country-group classification used by the VAT Declaration page. |
| Total HT | Total amount excluding VAT. |
| Total TTC | Total amount including VAT. |
| Currency | ISO 4217 code. |
| Status | Status badge — code + label, coloured by family. |
| Send to PA | Destination of the invoice: For the platform, Not for the platform or Held for review before sending (list-send-pa), filterable. |
| Review | Coloured review badge — Pending (awaiting customer service) or Reviewed. Lit up when the row needs operator attention — a status the dispatcher could not auto-resolve, a manual edit flagged on save, or a downstream system marking the row for re-check. It also lights up for an invoice Deposited (200) with reason NON_TRANSMISE: not an error, but the recipient has no active reception address, so the operator must forward it manually — other 200s keep a quiet dash. An invoice corrected by hand — saved from the invoice window or repaired with Fix buyer — is flagged Reviewed as soon as the validation that follows raises no error, whatever its status. Empty when nothing is pending: a few badges in an otherwise clear page tell you exactly where to start. |
A page-size selector at the bottom defaults to 50 rows per page; values up to 500 are accepted. The total count of matching invoices is shown next to the pagination controls.
Catalog columns
The Invoices view's SQL now joins F564231 (UH) and F564230 (FE) on doc / dct / kco via a LEFT JOIN, so the column catalog exposes 16 additional archive / log columns. Any of them can be added to the spec via the List Views editor's + Add column picker — the LEFT JOIN keeps invoice rows when no log entry exists.
| Catalog column | What it carries |
|---|---|
logSourceFile | Name of the source file that produced the invoice. |
logActivityCode / logSubType | Activity code and sub-type recorded at ingestion. |
logAlphaKey | Alpha-key alias used by some upstream systems. |
logAmount | Amount carried by the log row (raw, no currency rebase). |
logInvoiceDate / logDueDate | Invoice date and due date recorded at ingestion. |
logCreated | Creation timestamp (UPMJ + UPMT composite). |
logUser / logJobn / logPid / logVersion | JDE user, job, PID and version stamps. |
logBusinessUnit | Business unit recorded at ingestion. |
logRouting | BAR routing recorded at ingestion. |
logSendToPaFlag | Flag captured at ingestion telling whether the row was eligible for PA submission. |
logPaUuid | PA-side UUID assigned to the invoice at submission time. |
Click-through
Clicking any row opens the Detail modal for that invoice. Most actions are per-invoice, but the list also supports a bulk resend — see below.
Mark reviewed
Customer service marks the invoices in error it has handled as reviewed, so they leave the error counts and lists while Exclude reviewed errors is on. The invoice keeps its status.
- From the list — tick the invoices, then Mark reviewed (N). The button shows when at least one ticked invoice is in error and not yet reviewed. A confirmation says that the selected invoice(s) will be considered handled and will no longer appear among the errors to handle; only invoices still in error are marked.
- From the invoice window — the Reviewed chip at the right of the tabs sets the mark (dashed when not set) or clears it (green when set), each time after a confirmation. Clearing brings the invoice back among the errors to handle.
Both require the Mark reviewed action (invoice.review) on the Roles page. The mark is the Review column (UHALRTPSD).
Bulk resend
Each row carries a checkbox, and a Resend selected (N) button appears in the toolbar once at least one ticked row can be resent. It resends the whole batch to the Plateforme Agréée in one action, through the same progress window used elsewhere (live counters, Cancel, Run in background). The button counts and sends only the ticked invoices that can be resent under the resend rules — not a Do not send document type, not a Validation failed (9905), not a status the platform already processed. Such a row can still be ticked for a reprocess or a review. The server applies the same rules to each invoice of the batch.
Reprocess
A Reprocess selected (N) button appears next to Resend selected when the ticked rows include invoices eligible for reprocessing. Reprocessing is a reprint: for an invoice the platform deposited but did not transmit (status 200, reason NON_TRANSMISE), it regenerates the readable PDF / XML and the UBL file from the source archived at first processing (the source XML of an XML-source document, the XML produced by the conversion of a PDF-source document), into the output and burst folders. Nothing changes in the database and the UBL is not validated again — the stored e-invoice, including a later Fix buyer correction, stays the reference, and its validation results are kept. The invoice keeps its current status, a Retraitement entry is added to its history, nothing is re-sent to the platform, and each invoice is reprocessed only once. Only invoices on a document with Allow reprocess enabled (an XML- or PDF-source document — see Documents) are eligible; the others are ignored in the selection. The same run is available from the IT dashboard and the command line.
The selection also covers validation failures: an invoice in Validation failed (9905) on a template with Allow full reprocess enabled is reprocessed in full — enrichment queried again, UBL regenerated, validated and sent to the PA when the template and document type say so; the history is kept and a new cycle starts. The confirmation states which invoices are reprinted and which are reprocessed in full. The invoice window offers the same full reprocess through a Reprocess button on a 9905.
Several invoices are reprocessed as one batch per template, in the background with its live log: their sources are staged in a working folder, the Max threads global setting bounds the parallelism and an invoice is never processed twice. A single invoice still runs on its own.
Resend and reprocess rules
The server checks these rules on every resend and every reprocess, whatever starts it: the invoice window, the list selection, the IT dashboard cards, an Auto-retry job, the command line or the API.
Resend — the stored UBL sent to the PA again
| Condition | Rule |
|---|---|
| Status | Accepted for any internal 99xx status except 9905, 9911 and 9913: 9900, 9901, 9902, 9903, 9904, 9906, 9907, 9912… Refused for 9905 (Validation failed): a UBL that failed validation is never sent — correct the invoice (edit, Fix buyer) or run a full reprocess first. Refused for every standard platform status — any numeric code that does not start with 99 (1, 8, 10, 43, 45, 48, 200, 213…) — and for 9911 / 9913, stages the platform has already accepted. |
| Reason code | Not checked. |
| Document type | Refused when the send flag of the document type is Do not send (FEEV10 = 2). |
| Stored UBL | Refused when the invoice has no UBL stored in its header. |
| User | The Resend to PA action (invoice.resend) on the Roles page, and the invoice must be visible to the user. |
The invoice window hides Resend to PA whenever the server would refuse it: user without the permission, Do not send document type, 9905, status already processed by the platform. A call made anyway (API, older screen) ends with Validation failed (status 9905) — correct the invoice before resending or Already processed by the PA (status …) — resend refused.
A bulk resend — Resend selected, Resend all N on the dashboard, an Auto-retry job — selects the invoices (by status for the dashboard and Auto-retry: 9904 by default, or a list such as 9904,9907), then applies the same rules to each invoice.
The only opening in the protection is the Fix buyer repair of a Rejected (213) invoice for an addressing reason (ADR_ERR, REJ_ADR, DEST_INC), through its resend to the PA option — sent only when the revalidation passes.
Reprocess — two kinds, chosen from the status
| Kind | Status | Reason code | Document setting | Repeatable |
|---|---|---|---|---|
| Reprint — PDF and XML regenerated, nothing written to the database, no send | 200 | NON_TRANSMISE (exactly) | Allow reprocess = Y | No — once only: the 9912 marker left by the first reprint blocks a second one. |
| Full reprocess — regenerated with the enrichment queried again, validated, then sent when the settings say so | 9905 | Not checked | Allow full reprocess = Y | Yes |
Both kinds also require:
- the document recorded on the invoice (
UHTMPL) still exists; - that document has an XML or PDF source — a document with a UBL source cannot be reprocessed.
The send flag of the document type plays no part in the eligibility: a reprocess never sends by itself.
An invoice outside these rules — a 9904 for a reprint, a standard platform status for a resend — can only be moved on with Set Status. A 9905 is corrected, then validated again by the save or the full reprocess.
Export
A small Export button in the toolbar exports the current view (filters applied) as a CSV file named invoices.csv.
Detail modal
Clicking a row opens a modal with seven tabs along the top: Summary, Parties, Lines, VAT, Notes, History, PDF. The modal title shows the invoice's DOC / DCT / KCO triplet. At the right of the tabs, the Reviewed chip sets or clears the review mark of an invoice in error. A fullscreen toggle in the header switches between a windowed and a full-screen view.
Previous / next arrows (and the ← → keys) in the header move through the invoices of the list without closing the window — the same order and filters as the table on screen — with a position indicator (e.g. 3 / 50). Past the last invoice, navigation loops back to the first.
Summary tab (default)
The Summary tab shows a coloured status badge at the top — with, under it, the status details and the Rule set the invoice was produced under (see Rule sets) — followed by action buttons (Edit UBL, Copy, Delete) on the right. Delete removes the invoice and every related record — log row (source XML, PA transaction reference, source file name), lifecycle, lines, VAT and validation — so a later run of the same document starts fresh and the watched folders can pick its source file up again. Deletion follows the same protection as Fix buyer: the button is hidden once the PA has processed the invoice, except for a 213 rejection with an addressing reason. Right under the badge, when the platform returned them, the current rejection reason, expected action and status note are shown inline, and the full status message sits in a collapsed group — expand it for the platform's long error text. The same values feed the custom actions as {message}, {reasonLabel}, {actionLabel} and {actionNote} placeholders (see Actions), with no list-view column needed.
Fix buyer
The most frequent PA rejections are about the buyer's identifiers — SIREN (BT-47), SIRET (BT-46), intra-community VAT (BT-48) and electronic address (BT-49). A Fix buyer button opens a compact form pre-filled from the stored UBL, with the INSEE company search and the PPF electronic-address picker, to correct just those fields without re-editing the whole invoice. Only the changed identifiers are replaced inside the stored UBL — the rest of the document stays untouched — then the invoice is revalidated on the spot, an audit event records the old and new values in the history, and an option resends to the PA when validation passes. The button appears only while the invoice is still correctable — before the PA has taken it over, or when it was Rejected (213) for an addressing reason: ADR_ERR, REJ_ADR (the platform's addressing control) or DEST_INC (recipient unknown in the directory). In those three cases the invoice never reached the customer, which makes the resend safe; every other PA-processed status stays locked. A repair whose validation raises no error also marks the invoice Reviewed in the list. The buyer electronic address (BT-49) keeps the scheme already on the document — 0225 when there is none. The correction is logged as a plain history entry (Identifiants acheteur corrigés), without triggering the notification rule of the current status again, and the outcome of the new validation (9901 / 9902) is added to the history whenever it differs from the latest event. The keys stored on the row when the document was first processed (alpha key, customer number, business unit, routing code) are kept; the same applies to a save from the edit window. Format safeguards (SIREN/SIRET length and coherence, VAT shape) and the PA-protection rule apply — the same checks as the POST /api/invoices/{doc}/{dct}/{kco}/fix-buyer endpoint in the API reference.
Below the status, when the invoice is in a status that requires a follow-up action by the seller (e.g. 205, 206, 207, 208, 210, 213, 9904, 9907), a blue Seller actions banner appears with the recommended actions:
Status-by-status mapping:
| Status | Suggested actions |
|---|---|
| 205 Paid | Mark payment received |
| 206 Partially approved / 207 Disputed | Issue credit note, Issue corrected invoice |
| 208 Suspended | Send completed |
| 210 Refused | Cancel accounting |
| 213 Rejected | Cancel accounting, Issue new invoice |
| 9904 Send error / 9907 PA rejected | Resend to PA |
Each action is bound to an API connector endpoint configured in Configuration → API Connectors — clicking the button executes the connector with the invoice's data. Greyed-out actions (faded) indicate the connector is not configured for this deployment.
A second group sits below the regulatory one — Custom actions. Always-visible buttons configured on the Actions page; each fires its own chain of connector calls and is independent of the invoice's current status. The result banner is anchored to the group whose button fired — a custom-action failure does not stomp on a regulatory-action banner shown at the same time, and stale banners are cleared automatically when the modal closes or switches invoice.
The rest of the Summary tab presents collapsible groups:
- Document — DOC / DCT / KCO, UBL number, invoice type, profile ID, contract / buyer / order / project references, accounting cost.
- Dates & Currency — issue date, due date, currency, period start / end.
- Amounts — total HT, total TTC, amount due.
- Payment — payment means code, IBAN, account name, BIC, payment ID, payment terms.
- Document allowances / charges — document-level discounts or charges with type, reason, amount, tax category.
Parties tab
Three collapsible groups, populated from the UBL document:
- Supplier — name, SIREN, SIRET, VAT identifier, electronic endpoint, postal address, contact (name, phone, e-mail).
- Customer — name, company ID, electronic endpoint, VAT, address, contact.
- Agent Party (optional) — for the French extension — name, address, country.
- Delivery (optional) — date, party name, location ID, address.
A group with no data on the invoice is not displayed.
123 456 789123 456 789 00012FR121234567890009:1234567890001275001 Paris · FR
987 654 321FR989876543210009:9876543210001569002 Lyon · FR
2026-04-260088:301234560000369800 Saint-Priest · FR
Lines tab
A table of the invoice line items, one main row per line plus sub-rows that surface the additional information carried by the UBL.
| Column | Description |
|---|---|
| Description | Free-text description of the line item. |
| Item | Item identifier (article code, SKU). |
| Quantity | Quantity invoiced. |
| Unit | Unit-of-measure code (e.g. EA piece, H87 unit, DAY day, KGM kilogram). |
| Unit price | Unit price excluding VAT. Shown to its full precision — up to 6 decimals (BT-146), matching the source. EN 16931 allows finer precision on the price than on the monetary totals, which stay at 2 decimals. |
| Line amount | Quantity × unit price (excluding VAT). |
| Tax category | UBL VAT category code (S standard, AE reverse charge, E exempt, Z zero rate, O out of scope, K intra-EU, G export, L Canary Islands, M Ceuta/Melilla). |
| Tax rate | Applicable VAT rate as a percentage. |
Sub-rows appear under each main row for:
- Item description
- Period (start → end)
- Buyer / standard / classification item identifiers
- Line note (
BT-127) - Price-level allowance / charge (
BT-147) - Line-level allowances / charges (
BG-27/BG-28) - Additional item properties (
BG-32)
When several lines share the same delivery group, document references (BT-128) or customer order number (EXT-FR-FE-135), a delivery header, a document-reference header or a Customer Order Reference header appears once at the top of that group rather than repeating on every line.
VAT tab
A table of the VAT subtotals carried by the UBL: category code, rate, taxable base, VAT amount, currency, exemption code + label (when applicable).
Notes tab
Document-level notes (BT-22). Each note appears as a card with a prefix badge (e.g. PMD, PMT, REG) and the free-text body. The prefix label is resolved from the note-types reference list; hovering on the badge shows the label.
History tab
Three sections in this tab:
Action bar at the top
| Button | Behaviour |
|---|---|
| Validate UBL | Re-runs XSD + Schematron validation on the UBL stored in the database. The result is shown inline (valid / warning / error) with details when applicable. |
| Set status | Opens the Set Status modal — see below. |
| Resend | Submits the UBL to the Plateforme Agréée again. Confirms before running. |
| Download UBL | Saves the archived UBL of the invoice. |
| Download CII | Shown when the document has a post-transform: the archived UBL converted on demand, named after the post-transform (Download converted file when it has no name). |
Lifecycle group
The lifecycle is the audit trail of every status the invoice has been in. Each event shows:
- The status badge (code + colour-coded family).
- The status label and the message returned by the platform.
- Optional details for refusals: rejection reason code + label, expected action code + label, additional status note.
The lifecycle is append-only — events are added by the Sync → Retrieve Statuses sweep and never modified. Each event does carry a delete button (with confirmation): removing an event realigns the invoice status on the last remaining one — the clean manual fix when the platform delivered a stray status (a Refusée it later superseded, say). It is gated by a dedicated Delete lifecycle event action in the roles.
The three refusal fields — rejection reason, expected action and status note — also live in the column catalog, so they can be pinned as list columns and filtered from the List Views editor when a team needs to scan or sort by refusal reason without opening each invoice.
RR-016 — Quantity mismatch with deliveryAC-04 — Issue corrected invoiceValidation errors group
Lists the validation errors (XSD / Schematron) that were recorded for this invoice. Each row carries the severity, the rule identifier and the human-readable message. Empty when the invoice validates cleanly.
PDF tab
The PDF tab renders a generated PDF of the invoice inline (an <iframe> view). The bottom of the tab carries:
| Button | Behaviour |
|---|---|
| Opens the E-mail modal with the displayed PDF pre-attached. | |
| Download | Saves the PDF to the local computer. |
Action modals
Set Status modal
Opens from the History tab's Set status button. Lets the user move an invoice to a chosen status — useful for manual corrections or for triggering a transition the platform itself did not pick up.
| Field | Description |
|---|---|
| Target | PA (sends a status update to the Plateforme Agréée) or DB (writes the new status directly to the local database without notifying the PA). |
| Status | Drop-down listing every status from the statuses reference list, with code + label. |
| Status at (PA only) | Date / time of the status event. Default: now. |
| Reason | Free-text reason / message. Pre-populated with the status label; editable. |
| Rejection reason code + label (when applicable) | Code from the rejection-reason-codes reference list, plus its translation. |
| Action code + label (when applicable) | Code from the action-codes reference list, plus its translation. |
When Target = DB is selected, an orange notice reminds the user that the change is local-only and will not be propagated to the PA.
Click Submit to apply. A green banner confirms success; the modal closes after a short delay.
E-mail modal
Opens from the PDF tab. Lets the user send the invoice PDF to the customer via SMTP using the credentials configured in the global template.
| Field | Description |
|---|---|
| To (required) | Recipient e-mail address. |
| Cc | Optional carbon copy. |
| Subject | Pre-filled with Invoice <ublNumber>; editable. |
| Body | Pre-filled with a French / English template depending on the user's language: greeting, main line referencing the invoice number and total amount, contact line, signature. Fully editable. |
The PDF currently shown in the PDF tab is automatically attached. If the PDF was not pre-loaded, the server fetches it from the database before sending.
While the e-mail is sending, an overlay covers the modal until the SMTP server confirms the send. A green banner indicates success; the modal closes automatically after ~2 s.
Create / Edit invoice modal
Opens from + New Invoice in the toolbar, or from the Edit UBL / Copy buttons in the Summary tab. Lets the user create a new invoice from scratch or adjust an existing one. The modal is laid out like a printable invoice — the user fills the form and NomaUBL produces the corresponding UBL document on Save.
The sections and fields shown depend on the user's role: a role granted entry forms opens the editor on its default form — some fields read-only or hidden, defaults filled in, required fields checked on save — and a picker in the header switches between its forms. Without any form, the role keeps the complete editor. On a line, + Price opens the price details (gross price, price discount, net price) and + Delivery the line delivery block; the bin closes them.
Editing an existing invoice no longer flips its cbc:CustomizationID back to the EN16931 default. The form now carries the customizationId value from the source UBL and writes it back verbatim — new invoices still default to urn:cen.eu:en16931:2017.
The modal is split into vertical sections:
- Document — invoice number, type, profile ID, contract / buyer / order references.
- Header — issue / due dates, currency, period start / end, the Despatch advice (BT-16 — number and date), plus a Preceding invoices block (BG-3, 0..n): each row a reference number (BT-25) and an optional issue date (BT-26), added or removed with ＋ Add a preceding invoice (BG-3). On a credit note this is the reference to the corrected invoice.
- Supplier — pre-populates from the supplier directory (UBL Defaults → Suppliers / Companies); editable per invoice.
- Customer — filled end to end from the company search: results show the badge, name and identifier on one line with the address below; searching a bare SIREN or SIRET lists every establishment (the same second INSEE lookup as E-Directory), and an optional SIRET field completes the SIREN. The electronic address is not guessed from the SIREN/SIRET — a PPF electronic-address list (opened automatically after picking a company, or anytime via the button next to the identifier field) shows the addresses registered for the SIREN with their active/disabled state; picking one fills the identifier and its scheme, then the list closes. An Other ids (BT-46) block adds any number of extra buyer identifiers, each with its scheme from the EAS list — a routing code or a second SIRET carried on the document is now visible, editable and removable instead of travelling invisibly.
- Delivery — optional document-level delivery group (BG-13). It shows only the delivery set at document level; deliveries carried by the lines stay on the lines and are never copied up to the header.
- Payment — payment means code, IBAN, BIC, mandate, terms.
- Allowances / charges — document-level discounts / charges.
- Notes — free-text notes per
BT-22prefix. - Lines — invoice lines with item, quantity, unit, price, allowances, item properties. The unit-price input accepts fine precision (up to 6 decimals), to match prices that carry more than 2 decimals at source. A per-line Price (BG-29) block sets the gross unit price (BT-148) and the price discount (BT-147); the net price is derived and drives the line amount, and the line amount divides by the price base quantity (BT-149) so a price per 100 or 1,000 units is computed correctly. The line References block also holds per-line Preceding invoice references (EXT-FR-FE-136) — number, optional date and a DocumentStatusCode picked from
INFORMATION/DETAIL/GROUP. Three quick-add buttons in the same block fill the order references of the line, all carried bycac:OrderLineReference: Customer Order Reference (the buyer's order number, EXT-FR-FE-135 — the key the PDF groups lines on), Order number (the seller's order number, EXT-FR-FE-144) and Customer line no. (the line number inside the buyer's order, BT-132). A fourth button, Despatch advice, adds the line's despatch advice reference and date (EXT-FR-FE-BG-07). - VAT summary — auto-computed from the lines (read-only — line edits are reflected here).
- Totals — auto-computed (read-only).
The Save button at the bottom validates the input, writes to the database, generates the UBL document and submits it to the PA according to the e-invoicing template's settings. The modal closes after a successful save.
A fullscreen toggle in the header swaps between windowed and full-screen edit, useful for invoices with many lines.
Resend confirmation
The Resend button (in the History tab, or via Seller actions when status is 9904/9907) opens a confirmation dialog before re-submitting the UBL to the Plateforme Agréée, within the resend rules — the document is transmitted immediately and its status moves to Pending (9906). After confirmation, the invoice is re-submitted; an inline banner reports success or the error returned by the PA. The lifecycle is updated to reflect the new submission.
Tips & best practices
- Start with the period. Yesterday is the typical morning view, a custom range covers month-end reconciliation; set the opening period once under Default periods. Filters apply on top of the period.
- The stages are the fastest filter. To correct and Decision needed with a non-zero count are usually the right place to start when chasing exceptions; the caret narrows the stage to one status.
- The lifecycle (History tab) is the source of truth. It records every status the invoice has been in, with messages, rejection reasons and expected actions — the place to investigate disputes or PA-side decisions.
- Use the Seller actions banner. The actions surfaced for
205/206/207/208/210/213/9904/9907are the platform's recommended next step. They reduce a multi-step workflow (finding the customer, drafting the credit note, etc.) to a single click when the connector is configured. - Set status only when needed. Manual
Set status → DBdesynchronises the local record from the PA. Reserve it for clean-up after restoring backups or for statuses the lifecycle sweep cannot catch. - Edit UBL, then save is the canonical correction path — it rewrites the database record with the new UBL and re-submits to the PA. Avoid editing the source XML directly through UBL Tools → XML Viewer unless the data on disk is the authoritative one.
- Use Copy for recurring billing. It pre-fills every party / line / VAT field; only the document number, dates, and any specific changes need to be edited.