A Lightning invoice is a structured request for payment. BOLT 11 encodes information that a payer can use to attempt that payment, including a payment hash and timing fields. A merchant's accounting process needs to connect the request with the eventual settlement evidence rather than treat the creation of an invoice as revenue received. Lightning Network specifications — BOLT 11 payment encoding ↗
Use the invoice's own expiry information
The distinction is particularly useful when a customer scans a QR code, waits and then asks whether another attempt is necessary.
BOLT 11 defines a timestamp and an expiry interval. If the expiry field is absent, the specification provides a default of 3,600 seconds. It says the payer should not attempt payment after the timestamp plus expiry has passed and the payee should not accept payment after that point. These are invoice rules; they do not promise that every payment attempted before the deadline will find a successful route. Lightning Network specifications — BOLT 11 payment encoding ↗
For illustration, an invoice issued at 10:00 UTC with a 600-second expiry reaches that boundary at 10:10 UTC. A checkout displaying a 30-minute timer for the same request would be communicating different terms. The timer should be derived from the encoded request or clearly explain any separate commercial deadline.
Expiry is also distinct from a record of what happened earlier. An invoice whose time window has ended might already have been settled. Its age alone cannot determine whether the merchant received the payment.
Retain the request and settlement evidence together
Lightning Labs' LND documentation describes the AddInvoice endpoint as creating an invoice and returning a payment request and an index. It explains that invoice-based payments use a recipient-set preimage that can provide cryptographically verifiable payment evidence. Lightning Labs — LND: Receiving Payments ↗
The evidence needs context. A payment hash, its matching preimage and the relevant signed invoice can support a technical payment claim, but a business record must still connect that claim to the right order, amount and customer interaction. A cryptographic relationship does not itself establish that the merchant delivered the goods or resolved a separate commercial dispute.
Separate invoice payments from other receipt methods
The same LND documentation contrasts invoices with Keysend, where the sender supplies the preimage and the receipt model differs. A system handling both should identify which flow produced each payment. Assuming every incoming Lightning transfer has the same invoice-based evidence would make the reconciliation incomplete. Lightning Labs — LND: Receiving Payments ↗
For a practical audit trail, preserve the business order reference, original invoice, requested amount where specified, expiry, observed settlement state and the node's payment reference. If a replacement invoice is issued, link it to the original order and check whether an earlier invoice has already settled.
This organization gives customer support a useful answer to a familiar question: what was requested, and what was actually received? It also prevents a newly generated QR code from obscuring an existing payment while keeping the commercial order history intelligible outside the wallet interface.