When Should an Invoice Be Issued?

When an invoice is issued relative to payment depends on how the business collects money from its customers. A business may issue an invoice before payment, generate and finalize an invoice when a billing event occurs and then collect payment automatically, or provide a receipt after successful payment.

These approaches support different commercial models. Pay-by-invoice is common in B2B, where a customer receives an invoice with payment terms and settles the amount later. Subscription businesses using automatic card payments typically create an invoice as part of the billing cycle and then attempt to collect the amount due. In straightforward consumer payments, the customer may pay immediately and receive a receipt afterwards.

The decision is therefore not simply about when a document is created. Invoice timing affects payment collection, accounts receivable, dunning, reconciliation and the relationship between the billing system and the PSP. The business should define the invoice lifecycle together with the payment flow rather than treating invoicing as a separate document-generation function.

Invoice Before Payment: Pay-by-Invoice

The clearest case for issuing an invoice before payment is pay-by-invoice. The customer receives the invoice first, and the invoice specifies the amount due and the payment terms. Payment is then made later, often by bank transfer or another accounts-payable process.

This model is particularly common in B2B invoicing, where customers may have agreed terms such as Net 30 or another payment period. The invoice therefore creates an outstanding receivable that remains open until the customer pays it.

Enterprise financial systems such as SAP are designed to support this type of process. SAP accounts-receivable functionality uses payment terms to determine the due date and can also calculate applicable cash discounts.

The payment architecture is consequently centred around accounts receivable. The invoice exists independently of the payment, and the eventual payment needs to be matched against the outstanding invoice. Overdue invoices can then be handled through reminders and dunning processes.

This approach makes sense when the customer is not expected to pay at the moment the invoice is issued. It is less relevant for a standard consumer checkout where payment is expected immediately.

Invoice Created Before Automatic Payment

For subscriptions and other automatic payment models, the invoice is often created as part of the billing event and then used as the basis for payment collection. The important distinction is that the invoice and the payment attempt are separate events, even when they happen only seconds apart.

Stripe Billing, for example, creates invoices for subscription billing periods and finalizes the invoice before it can be paid. With automatic collection, Stripe can then attempt to charge the customer's stored payment method.

The flow is therefore better understood as:

Billing event → Invoice created → Invoice finalized → Payment attempted → Invoice paid or remains open

This distinction becomes important when a payment fails. The invoice does not simply disappear because the card was declined. It can remain outstanding and become part of the business's failed payment and dunning process.

Chargebee follows a similar model. Its documentation describes recurring invoices being generated for subscriptions and automatic collection being attempted when the invoice is generated. If payment fails, the invoice can move into a payment-due state and dunning can handle subsequent payment attempts.

This model is particularly suitable for subscription billing because the invoice provides a persistent record of the amount due even when the initial payment attempt is unsuccessful. The same invoice can then remain connected to subsequent collection attempts.

Payment Before Receipt or Customer Confirmation

A different flow is common in straightforward consumer transactions: the customer pays first and receives a receipt or payment confirmation afterwards.

This is typical when the customer is actively completing a checkout and there is no outstanding payment obligation. The immediate requirement is to confirm that the transaction succeeded, rather than to give the customer a period in which to settle an invoice.

It is important, however, to distinguish a receipt from an invoice. A receipt confirms that payment has been made. An invoice documents the underlying sale and the amount payable and can form part of the seller's accounting and tax records. The applicable invoicing requirements depend on the transaction and jurisdiction.

This means that a customer-facing flow such as Checkout → Payment successful → Receipt does not necessarily mean that the business has no invoice or accounting document behind the transaction. The customer-facing receipt and the company's financial records can be managed separately.

Why Invoice Timing Matters for Payment Architecture

The timing of the invoice determines how the billing system, PSP and financial system need to interact.

With pay-by-invoice, the invoice exists before payment and becomes an open receivable. The customer can pay against that invoice later, and the payment needs to be reconciled with the outstanding balance. The business can therefore manage payment terms and overdue invoices independently of the original invoice creation.

With automatic subscription payments, the invoice is created from the billing event and the PSP is instructed to collect the amount due. If payment succeeds, the invoice is marked as paid. If payment fails, the invoice remains outstanding and the dunning process can determine what happens next. Chargebee, for example, explicitly connects invoice status with automatic collection and dunning.

With a receipt-after-payment model, the successful payment becomes the trigger for the customer confirmation. The PSP or payment integration provides the transaction information needed to generate the receipt, while invoicing and accounting can remain part of a separate financial process.

This is why invoice timing, payment collection and dunning should be designed together. A payment failure is not simply a failed transaction; depending on the model, it may leave an invoice outstanding and create a subsequent collection process.

Pay-by-Invoice vs Automatic Payment

The practical difference between the two main models is the point at which the customer becomes responsible for paying the amount.

With pay-by-invoice, the business creates the invoice and gives the customer a payment period. The invoice can remain open for days or weeks, and the payment process is driven by the agreed payment terms.

With automatic collection, the business creates the invoice and attempts to collect the amount immediately or according to the configured billing schedule. If the payment fails, the invoice can remain open while the business retries payment or starts its dunning process.

This distinction also affects the systems involved. Pay-by-invoice generally requires stronger accounts-receivable and payment reconciliation capabilities. Automatic subscription payments require close integration between the billing engine, payment provider and failed-payment process.

When Should Each Invoice Timing Model Be Used?

Issue the invoice before payment when the commercial model gives customers payment terms. This is particularly relevant for B2B customers, purchase-order-driven processes and businesses where accounts payable processes the invoice before payment is made.

Create the invoice as part of the billing cycle and collect payment automatically when customers are expected to pay immediately or on each subscription renewal. This is the typical model for many recurring card-payment businesses because the invoice, billing event and payment attempt remain connected.

Provide a receipt after payment when the customer pays immediately and mainly needs confirmation of the successful transaction. A separate invoice may still be generated depending on the company's invoicing and accounting requirements.

Many businesses will use more than one of these models. A subscription business may automatically charge consumers while allowing larger B2B customers to pay against an invoice. The important point is not to force every customer into the same payment flow.

How Invoice Timing Affects the PSP

The PSP should be selected based on the payment and billing architecture, rather than simply on whether it can generate an invoice.

For automatic subscription billing, the PSP or integrated billing provider needs to support the relationship between the subscription, invoice, payment attempt and payment status. It should also provide the events and APIs required to keep the billing system informed when a payment succeeds, fails, is refunded or requires another collection attempt.

For pay-by-invoice, the requirements are different. The business may need to generate invoices in an ERP or billing platform, provide payment instructions to the customer and then reconcile incoming payments against the outstanding invoice. In this model, the PSP may be only one part of the payment collection process.

The architecture should therefore define which system generates the invoice, when the invoice becomes payable, which system initiates the payment, and which system remains the source of truth for the invoice status.

Choosing the Right Invoice Timing Model

There is no single best way to issue an invoice relative to payment. The correct model follows from the way the business sells and collects money.

Pay-by-invoice works best when customers receive payment terms and the invoice becomes an outstanding receivable. Automatic invoice collection is generally better suited to subscriptions and recurring payments where the customer is charged as the billing period begins or renews. Receipt-after-payment is common for straightforward consumer transactions where payment is completed immediately.

Before implementing the payment flow, the business should therefore define when the billing obligation is created, when payment is expected, when the invoice is finalized, what happens when payment fails, and which document the customer receives.

Once these decisions are clear, the technical requirements become easier to map. The right PSP is then not simply the provider with the strongest invoicing feature set, but the provider whose invoice lifecycle, payment collection, dunning, receipts and integrations fit the wider billing architecture.

Getting this distinction right early can prevent a common problem: a payment integration that works technically but does not match the company's actual billing, accounts-receivable and financial processes.