Who Generates Invoices? Choosing the Right Invoicing Model

Subscription businesses need to decide where invoices are generated and, more importantly, where the billing logic behind those invoices is managed.

The payment service provider (PSP) can generate the invoice as part of its subscription billing functionality. Alternatively, a dedicated billing platform can calculate the amount due and generate the invoice, while the PSP only processes the payment. In an enterprise environment, the billing and invoicing process may instead sit within an ERP or an internal finance system.

The choice affects more than the invoice itself. It determines which system knows what the customer should be charged, how subscription changes are reflected, how failed payments and refunds are handled, and how payment information ultimately reaches the company's accounting system.

There is therefore no universally correct model. The right approach depends on the complexity of the subscription model and on where the business already manages its financial and billing processes.

Invoices Generated by the PSP

The most integrated approach is to let the PSP manage subscription billing and generate the invoices. The PSP maintains the subscription, determines when the next billing event occurs, calculates the amount due, generates the invoice and attempts to collect the payment.

Stripe is a prominent example of this model. Stripe Billing automatically creates invoices for subscription billing periods and can collect payment using the customer's saved payment method.

For a straightforward subscription business, this can provide a relatively simple architecture. The subscription, invoice, payment method and payment attempt are managed within the same environment, reducing the number of systems that need to exchange information.

The trade-off is that the PSP becomes part of the company's billing architecture, not just its payment infrastructure. The business is therefore dependent on the provider's capabilities for pricing, billing cycles, discounts, prorations, usage and other subscription requirements. This may work well for a standard SaaS subscription but can become more restrictive as the billing model becomes more complex.

This model can therefore be attractive when simplicity is the priority and the PSP's billing capabilities closely match the business model.

Invoices Generated by a Dedicated Billing System

A business can instead separate billing from payment processing by using a dedicated billing platform.

In this model, the billing system manages the subscription and determines what the customer owes. It generates the invoice and then instructs the PSP to collect the corresponding amount. The PSP remains responsible for payment processing, while the billing platform manages the billing lifecycle.

Chargebee is an example of this approach. Its subscription model connects plans, addons, discounts and other charges to invoices, while its billing platform integrates with payment providers for payment collection.

This separation can be useful when the subscription model requires more sophisticated billing logic. The billing system can manage different billing frequencies, usage-based charges, discounts or prorations without requiring the PSP to become the owner of those commercial rules.

The additional flexibility comes with an additional integration requirement. The billing platform needs to tell the PSP what amount to collect, while the PSP needs to return payment results so that the billing platform can keep the invoice and subscription status up to date.

The important point is that the billing system should normally remain the source of truth for the amount owed. The PSP should execute the payment rather than independently calculating a competing subscription charge.

Invoices Generated by an ERP or Internal System

The third approach is to generate invoices through an ERP or the company's own internal system.

This is particularly relevant where invoicing is already part of an established finance and accounting process. The ERP may determine the amount due and maintain the invoice and accounts-receivable record, while the PSP is used to collect the amount specified by the ERP.

SAP is an example of how this can work in an enterprise architecture. SAP Subscription Billing separates subscription rating and billing from invoicing, with billing information being transferred to SAP or non-SAP applications for invoicing.

A typical flow could therefore look like:

Subscription and billing logic → ERP generates invoice → PSP collects payment → payment result returned to ERP

This approach can fit naturally into an existing financial architecture. It also avoids creating a second set of invoices inside the PSP when the ERP is already responsible for the company's financial records.

The trade-off is that the integration becomes more important. Payment failures, refunds, credits and other adjustments need to be communicated between the PSP and the ERP and reflected correctly in the financial records.

Where Should the Billing Logic Sit?

The most important architectural decision is therefore which system determines what the customer owes.

The system generating the invoice should generally be the system that owns this billing logic. If the PSP manages the subscription and determines that €100 is due, it can generate the invoice and collect the €100. If an external billing system or ERP determines that amount, it should generate the invoice and instruct the PSP to collect it.

This becomes increasingly important as subscription billing becomes more sophisticated. The amount on an invoice may depend on the subscription plan, billing period, discounts, usage, prorations, upgrades or other adjustments.

Duplicating this logic across systems should generally be avoided. If an ERP calculates one amount while the PSP independently calculates another, the business has created two competing versions of the billing process. The result is additional reconciliation and a much harder-to-maintain integration.

The architecture should therefore have a clear source of truth for billing, with the other systems consuming and updating the relevant information.

Invoicing and Payment Are Different Events

An important distinction is that generating an invoice and collecting a payment are separate events.

An invoice can exist even when the payment has failed. A subscription payment flow can therefore look like:

Invoice generated → Payment attempted → Payment fails → Invoice remains outstanding → Payment retried → Invoice paid

This becomes particularly important for failed payments and dunning. If a billing platform or ERP owns the invoice while the PSP processes the payment, the payment result needs to flow back to that system. It can then determine whether the invoice remains open, whether another payment attempt should be made, or whether the subscription should eventually be paused or cancelled.

The same principle applies to refunds. A customer may receive a refund after an invoice has already been paid. The payment is reversed, but the financial effect still needs to be reflected in the billing or accounting system.

This is why invoicing, payment collection, dunning and refunds should be considered together. They form one financial process even when different systems are responsible for individual steps.

The Role of the ERP

The question becomes particularly important when an ERP is already the company's financial system of record.

A business may have a dedicated billing platform managing subscriptions, an ERP managing invoices and accounting, and a PSP processing payments. Another business may use the PSP for subscription billing and invoicing and send the resulting financial information to the ERP.

Both architectures can work. The important point is to define which system owns each responsibility.

If the ERP is already responsible for invoices and accounts receivable, generating another set of invoices through the PSP can create unnecessary reconciliation work. Invoice numbers, amounts, taxes, payment status and refunds may then need to be synchronised across both systems.

On the other hand, an ERP does not necessarily have to generate the customer-facing invoice. A billing platform or PSP can generate the invoice while the ERP receives the financial information it needs for accounting.

The key is therefore to establish one authoritative billing and financial record, rather than allowing several systems to independently create and maintain the same information.

Choosing the Right Invoicing Model

For a straightforward subscription model, PSP-generated invoices can provide the simplest architecture. The subscription, billing event, invoice and payment remain closely connected and require fewer integrations.

A dedicated billing platform can be more appropriate when the business has more complex subscription logic or wants to keep billing independent from the payment provider. This provides greater flexibility while allowing the PSP to remain focused on payment processing.

An ERP or internal system can be the right approach when invoicing is already deeply connected to the company's financial and accounting processes. In this model, the PSP can remain primarily a payment execution layer.

Before selecting the approach, the business should therefore be clear about where the billing logic lives, which system generates the invoice, which system processes the payment, and which system is the financial source of truth.

Once these responsibilities are defined, the technical requirements become much easier to map. The right PSP is then not simply the one that offers the most invoicing features, but the one whose billing, payment and integration capabilities fit into the wider subscription and financial architecture.

For a growing subscription business, making this decision early can prevent duplicated billing logic, difficult reconciliation and unnecessary changes to the payment integration later.