Why invoiceable: false on a charge stops wallet credits and PSP charges from being collected

Last updated: June 30, 2026

Setting invoiceable: false on a charge keeps that charge's fees off the customer's regular subscription invoice. Because both wallet credit drawdowns and PSP charges (such as Stripe) require an invoice to fire, fees that never land on an invoice are never collected. If you expected a wallet to be drawn down or a card to be charged for these fees and nothing happened, this is why.

How invoiceable: false works

invoiceable: false is a setting on a charge, not on a subscription. When a charge has it set, its fees are still created and tracked, but they are not attached to the billing period invoice. The subscription's normal invoice is still generated and still includes every other invoiceable charge. The non-invoiceable fees exist as standalone fee records with no invoice association.

invoiceable: false is only valid on a charge that also has pay_in_advance: true. The two are enforced together by model validation, so you cannot set invoiceable: false on its own.

Why payment never fires without an invoice

Both PSP charges and wallet credit drawdowns operate at the invoice level. A standalone fee with no invoice does not produce a payment intent and does not trigger a wallet debit. So a charge configured with invoiceable: false generates fees, but those fees sit unpaid unless you do something to settle them. There is no automatic collection for them.

What to use depending on what you want

To collect payment automatically, including wallet credit drawdown, set invoiceable: true on the charge. The fees then appear on the regular subscription invoice and go through normal payment collection, the same as any other charge.

To keep the fees off the subscription invoice but still produce a consolidated billing document, set regroup_paid_fees: :invoice (which also requires pay_in_advance: true and invoiceable: false). This gathers standalone non-invoiceable fees that you have already marked as paid and groups them into a separate advance_charges invoice. It does not collect payment. Lago marks the invoice as paid and records a manual payment entry for the total, on the assumption that the fees were already settled out of band. You settle each fee yourself and mark it succeeded through the Fees API, and Lago then bundles the already-paid fees into the consolidated invoice for the record. The grouping happens during the customer's billing run, and also on subscription activation and termination, not at the moment each fee is created.

If your goal is to charge customers per event without generating a per-event invoice, see: https://knowledge.getlago.com/articles/7525948982-how-to-charge-customers-per-event-without-generating-a-per-event-invoice


This article reflects guidance drawn from customer case resolutions. It is not officially supported documentation and may not apply to all situations.