Invoicing & Credit NotesCopy Anchor Link

Invoices are the accounting backbone of your transactions. The Payment Gateway generates locked invoice PDFs and configured e-invoice XML formats for successful captured payments. Your organization remains responsible for validating document settings, numbering, tax treatment, and jurisdiction-specific legal requirements.

Document Detail ViewsCopy Anchor Link

In the Admin UI, invoice and credit note detail pages use the same party structure:

• Seller: The legal entity issuing the document.
• Client: The billed counterparty shown on the document snapshot.

This keeps invoices, credit notes, and transaction detail views consistent inside the admin control plane.

When the document is linked to a stored Client record, the Client email in the detail view links directly to that Client profile. This gives operators a quick path from a document to the broader relationship history without changing the legal document itself.

The document still preserves its own party snapshot, including the buyer Peppol routing address when present. If the current Client profile changes later, the already-issued invoice or credit note continues to show the original document data that was valid at issuance time. For issued invoices, update the invoice snapshot through the correction workflow.

Invoice StatusesCopy Anchor Link

Invoices exist in strict states to maintain accounting integrity:

1. draft: The invoice is currently being constructed. You can edit line items, change the billing address, or delete it entirely without leaving an accounting trace.
2. issued: Once the "Issue" button is clicked (or a transaction succeeds automatically), ordinary draft editing is locked and an official sequential InvoiceNumber is permanently assigned. Later changes must use the audited correction workflow and satisfy its restrictions; refunds use separate settlement and credit-note workflows.
3. Payment state (computed): Whether an invoice is open, partially settled, settled, credited, refunded, or overpaid is derived from linked settlements and credit notes rather than stored as a separate mutable invoice status.
4. Void / return workflows: If an issued invoice is critically wrong or its payment must be returned, use the applicable document or payment workflow and keep the original invoice on file as part of the permanent accounting record.

Draft invoices can only download a pro forma PDF. XML e-invoices and hybrid ZUGFeRD / Factur-X PDFs become available after the invoice is issued because the final invoice number is assigned during issue. The eInvoice checks shown on a draft are pre-issue guidance: they identify seller, buyer, payment, tax, and Peppol routing data that users can fix before issuing, but they are not proof that XML can already be downloaded.

During a versioned accounting reconciliation, invoice actions can be temporarily unavailable. Version 2 automatically corrects the supported per-unit metadata mismatch when the complete invoice group is proven by retained issued evidence, including for installations blocked in or previously completed under version 1. The migration records system provenance and requires no administrator confirmation. The normal reconciliation runner must verify the complete group before invoice actions resume.

If automatic migration cannot prove the complete group and the Dashboard offers Review recovery, an organization administrator can inspect an explicit fallback plan across the issued invoice and its linked issued credit note. The preview names each document and line, shows exact before and after minor-unit values and formatted currency amounts, and shows the retained invoice, credit-note, payment, and chargeback totals used as evidence. Version 3 also shows every normal-runner verification effect, including any payment or chargeback classification aligned with the retained issued-invoice basis, plus the amounts and tax basis that remain unchanged. Technical evidence such as semantic digests, record IDs, recognition fields, and line-level proof is available in the expandable details. Confirmation is bound to that complete versioned preview; a stale preview, missing effects field, or older browser bundle cannot apply the multi-document plan.

Automatic migration and the reviewed fallback share the same evidence proof and fenced atomic mutation path. They change only evidence-proven per-unit net metadata on issued documents and preserve issued totals, tax rates and codes, tax and legal evidence, protected-field ciphertext, PDF versions and renditions, and document identities. When the verified plan contains a derived classification effect, the unchanged normal runner creates the replacement accounting record, retains the previous record as superseded history, and prevents the linked issued credit note and transaction adjustment from being counted twice in combined reports. Typed readback and an immutable audit record cover every document and derived effect. Unsupported encryption, missing or conflicting retained tax records, duplicate or foreign source ambiguity, an additional semantic mismatch, or concurrent evidence changes cause a refusal without a partial write. Unsupported blockers offer a diagnostic export instead; see Troubleshooting.

Entering AmountsCopy Anchor Link

Invoice line-item Unit Price Gross (minor units) and Unit Price Net (minor units) fields take whole-number minor units. This also applies to financial corrections and recurring schedule line items. Payment-link, credit-note, provider-refund and received-payment forms instead take amounts in the currency shown on the form.

The examples use a decimal point. Forms reject malformed amounts, unsupported fractional precision and amounts outside the safe integer range instead of silently changing the submitted value. Payment confirmation uses the payout currency when conversion occurred; its received amount may be left blank to use the backend default.

Line-item unit prices must be whole minor units; zero is valid, and discount items use negative prices. Invalid price or quantity text remains visible with an error and blocks saving the invoice, correction or recurring schedule until corrected. Enter whole quantities of at least one; the editor rounds valid fractional quantities to the nearest integer and enforces a minimum of one.

Draft Invoice Tax CalculationCopy Anchor Link

When creating or editing a draft invoice manually, VAT can be either automatic or explicit on a per-line basis.

1. Leave the VAT field blank to let the backend calculate tax automatically.
2. Enter a VAT percentage only when you intend to override the automatic result for that line item.
3. The Admin Panel previews the canonical backend tax result before save, including the resolved rate code when available. Server preview totals also apply to manual VAT overrides and respect the configured rounding mode. Editing preview inputs clears the previous result while recalculation is pending.

The same tax engine is used for transactions, recurring invoices, API-key draft invoice creation, and the draft-invoice preview endpoint, so the behavior stays consistent across flows. For lifecycle, OSS evidence, and ledger concepts, see Invoicing & Tax architecture; for POST /api/v1/invoices/preview-tax and tax report routes, see Admin API.

When a draft is issued, the invoice stores the resulting tax snapshot and writes canonical tax records. Depending on the organization tax recognition mode, those records are recognized at invoice issue time (accrual) or deferred until settlement (cash). Credit notes write separate offsetting tax records; the original invoice tax snapshot remains unchanged.

Correcting Issued InvoicesCopy Anchor Link

Use the correction workflow to update an issued invoice's party snapshot or, when eligible, its line items. A reason is required. Financial corrections record previous and new line items and totals in the audit history; they do not change the invoice number or perform a refund. Booked, refunded or credited invoices and invoices with multiple linked transactions cannot receive financial corrections. A linked transaction with refund or chargeback history also blocks them; with one eligible linked transaction, the corrected gross total and currency must match that transaction. See Invoice Corrections for the contract.

Payment LinksCopy Anchor Link

Issued invoices can have hosted payment links created manually from the invoice payment section or automatically during issue when Settings > Invoicing > Auto-create payment link on issue is enabled.

Manual invoice payment links default to the current outstanding amount, but operators can create a smaller partial-payment link. The backend caps the amount at the outstanding balance, enforces a minimum of 50 minor units (50 JPY, 0.50 EUR, or 0.050 KWD), and rejects empty or fully settled invoices.

Payment-link expiry uses the same invoicing setting as automatic issue-time links. If no value is configured, the default is 336 hours (14 days); explicit expiry values can be between 1 and 3120 hours.

For reverse-charge, export, exempt, zero-rated, and manual VAT outcomes, invoice checkout creation keeps the invoice tax snapshot but avoids sending synthetic tax-rate codes to checkout tax-rate lookup. When a transaction settles a partial link, the invoice settlement logic allocates tax proportionally from the invoice.

The Customer PortalCopy Anchor Link

Rather than emailing large PDF attachments that may be blocked by spam filters, the gateway hosts a secure Customer Portal.

End-users navigate to your custom domain (e.g., invoices.yourcompany.com) and authenticate using a one-time secure link, with OTP confirmation available where configured. From there, they can independently:

• Download portal-visible invoice and credit-note PDFs when PDF downloads are enabled.
• Pay eligible open invoices when a payment link is available.
• See scheduled finalization timing for draft recurring invoices when scheduledFinalizeAt is present.
• Download issued invoice XML: XRechnung, Peppol BIS 3.0 XML, or ZUGFeRD/Factur-X CII if configured.

E-invoice settings control XRechnung, Peppol, and ZUGFeRD readiness. Seller Peppol routing address is the seller EndpointID written into Peppol XML; use the sender address type and value configured by your Peppol service provider. Buyer Peppol routing address is the delivery address supplied by the recipient or their Peppol service provider. Choose the address type separately from the value; for example, select 0088 only for a supplied GS1 GLN or 0204 only when a German public-sector recipient confirms its Leitweg-ID as the Peppol receiver address, then enter only the identifier value without the prefix. Do not assume VAT ID is correct unless the recipient confirms a VAT-based Peppol address type. Germany-only: Leitweg-ID is the buyer/public authority reference for German public-sector invoices and should come from the order or contract.

Credit Notes (Refunds)Copy Anchor Link

A payment return and an accounting document are separate outcomes. The original invoice remains immutable.

When an invoice has one receipt-backed completed payment, Refund Payment opens that transaction's return workflow. With multiple linked payments, select the intended transaction in the Payment section. The transaction server decides eligibility from its verified receipt; invoice totals do not authorize a refund.

The currently exposed provider command initiates an eligible Stripe payout. Legacy manual refund and chargeback recording is unavailable, and the Invoice page does not call those routes. See Refunds and Returns.

A successful provider return does not prove that a credit note or tax adjustment exists. Receipt-backed return tax and document materialization remain pending until authoritative historical allocation is supported. Operators must not create a compensating sale, change the original payment date, or describe the provider result as a generated legal document.

When an invoice has no linked payment record, the separate Create Credit Note workflow may be available for a document-side full or partial reversal. Whether a credit note is legally required depends on the organization's jurisdiction and accounting process.

Existing historical refund, chargeback, tax, and credit-note records remain readable. A won dispute reverses the dispute effect; it does not cancel a separate refund. Final merchant-loss Customer Risk Holds remain a distinct control for future checkout routing.

Numbering ConfigurationCopy Anchor Link

Organizations control invoice and credit note numbering from the invoicing settings page.

Each organization configures two independent document layouts: one for invoices and one for credit notes.

Each layout can define:

• a dedicated prefix
• optional middle text between the visible period and the sequence
• an optional suffix
• the first sequence number to allocate
• the zero-padding width of the numeric sequence
• whether the visible period uses no date, the calendar year, or the fiscal year
• whether the sequence resets never, every calendar year, or every fiscal year
• how much of the issue date appears in the number
• how date parts are separated when month or day are shown

If a layout uses No date, the sequence is appended directly after the prefix unless you provide explicit middle text. This avoids accidental doubled separators for prefixes that already end in punctuation such as -.

Typical layouts include:

• No date → example: INV-0001
• Year → example: INV-2026-0001
• Year + Month → example: INV-2026-03-0001
• Year + Month + Day → example: INV-2026-03-27-0001
• Fiscal year with middle text → example: INV2027AR0001
• Fiscal year with suffix → example: CN-2026-0001-REV

When the separator is set to None, date parts are compacted:

• INV-20260327-0001

When fiscal numbering is enabled, the backend derives the year label from the actual issue date and the configured fiscal-year start month. That same fiscal definition also drives the optional fiscal-year reset policy.

Numbers are allocated sequentially from an organization-scoped counter shared by all sites. Administrators may make an explicit, audited forward adjustment to the active invoice sequence when continuing after invoice numbers issued outside the application. That operation can create an intentional gap; it cannot move backward or renumber existing documents. Changing the layout affects newly allocated numbers only. Existing invoices and credit notes keep their assigned document numbers permanently.

Continuing an existing invoice rangeCopy Anchor Link

Use Settings > Invoicing > Active invoice sequence > Set next invoice number after the first application-managed invoice exists in the active calendar or fiscal bucket. The review step shows the current and proposed formatted numbers, the active bucket, legal timezone, skipped count, and organization-wide scope. A reason of at least 10 characters is stored with the audit record.

The control is forward-only and uses optimistic concurrency: if another invoice is allocated while the dialog is open, refresh and review the new current sequence before confirming again. The configured Starting number applies only when a bucket is first created; it is not the control for changing an active sequence.

[!IMPORTANT] Set the next number before enabling automatic creation when external or manually issued invoices already occupy later numbers. The control adjusts only the bucket currently active in the organization's legal timezone. Invoice allocation continues resolving calendar or fiscal buckets from each invoice's issue date; historical backfill policy is outside this control.

PDF Storage and Download RecoveryCopy Anchor Link

Settings > Invoicing > PDF Storage supports private Amazon S3 and compatible providers. Without custom storage, worker files are a temporary delivery cache with approximately 24-hour cleanup, not a document archive. Failed cloud uploads are shown as generation failures, with retry guidance in the PDF dialog.

Saving storage settings does not test the connection. Follow PDF Storage for provider support, credential handling, verification, retention, and recovery. Review the impact on existing documents before changing or disabling storage.

Reminder delivery statusCopy Anchor Link

Automatic reminders and escalations use the notification queue. A queued attempt is not proof of delivery: sent requires a persisted successful SMTP receipt. failed describes a failure before the SMTP attempt or an exhausted job; safe preparation failures may still retry.

Scheduled reminders and escalations acquire a durable attempt marker immediately before SMTP. An unconfirmed attempt becomes held, not sent or a definitive delivery failure. It is not automatically resent. This includes an SMTP error, a lost receipt, or a crash after claiming the attempt but before actually sending. Ordinary invoice and OTP email retry behavior is unchanged.

Operators must check worker logs and SMTP provider evidence before any manual follow-up. A held reminder may already have reached the recipient. Do not clear the attempt marker or reset its job to force a retry. If the provider confirms non-delivery, use your reviewed manual communication process. The admin invoicing settings explain this policy; there is no dedicated reminder-history dashboard.

Interrupted scheduling resumes the same notification identity while delivery evidence remains available or the persisted intent is recent enough for safe recovery. If its notification is missing and the intent is at least 90 days old, or its creation time is missing or invalid, the reminder is held: normal cleanup may have erased a successful or ambiguous delivery. Recent interrupted enqueues can still resume. Notification retention remains 90 days for terminal records and 180 days for stale records; reminder history retains its 400-day cleanup policy. Legacy attempts without a notification link cannot be safely classified from age alone; inspect delivery evidence before manually resending them. A retained held log continues to suppress automatic recovery after notification removal. No exactly-once guarantee is made about external SMTP providers or manual sends.

All active SMTP workers must support the attempt guard. See worker rollout guidance.

Document Template CustomizationCopy Anchor Link

Organizations can create custom PDF document templates for invoices, pro forma documents, credit notes, and receipts under Settings > Templates. The template editor supports Designer mode, Advanced Source, custom variables, import/export, PDF proofs, publishable revisions, defaults, and explicit layout refresh for already-issued PDFs.

For the full workflow, source modes, variable placement, revision behavior, portal impact, and defaults, see Templates.

Receipt-backed paymentsCopy Anchor Link

New receipt-backed payments allocate against the original issued invoice receivable; a partial receipt does not issue a second invoice or fulfill the order early. Recording manual cash requires a stable bank statement evidence ID, receiving account identity, actual received timestamp and notes. See Receipts and allocation. Invoice assignment is not a substitute for recording receipt evidence.

Legacy refund, chargeback, and invoice-from-transaction mutations are unavailable for receipt-backed transactions. Eligible provider refund initiation is documented separately, while receipt return tax and document obligations remain pending. Do not create a compensating sales invoice or move the receipt date into the current reporting period.