How ERPNext subscriptions automate recurring invoices
A finance or operations lead who bills the same customers on a fixed cadence, and tracks renewals in a spreadsheet, is carrying two risks: invoices that go out late or not at all, and revenue that is recognized against contracts nobody has checked. ERPNext Subscriptions address the first risk by generating invoices automatically from a Subscription Plan that is linked to a customer or, on the purchasing side, a supplier. The plan defines the item, the price, the billing interval and the period, and the Subscription record then tracks that agreement from start to cancellation. Teams usually need this when they have a fixed recurring fee per customer, such as maintenance, hosting or a service contract, and when the number of agreements has grown past what manual invoicing can cover reliably.
The distinction from Auto Repeat matters when you choose a design. Auto Repeat repeats a general document, such as a sales invoice, journal or order, on a schedule, and the ERPNext documentation positions it for repeated documents in general. A Subscription is built for customer billing: it carries the plan, the status of the agreement and the renewal logic that a recurring fee needs. Before you build, confirm in your ERPNext version which subscription options are available, including how pricing, prorating, billing intervals, invoice timing and tax templates behave, and how Subscriptions interact with cancellation and trial periods. Check these against the Subscription documentation for your release, and test each option with a sample customer before you rely on it for production billing.
Choosing fixed, price list or prorated pricing
A fixed rate stores the amount on the Subscription Plan itself. Every subscription created from that plan bills the same price for each interval until someone changes the plan or the subscription. This is the simplest model to set up and to audit, since the amount is visible on the plan record and does not depend on any other master data. The trade-off is maintenance: a price increase has to be made on the plan, and you need to decide explicitly whether existing subscriptions should follow it.
- Ownership: the finance or revenue lead who owns the plan record maintains the amount, so access to edit plans should be limited to that role.
- Existing subscriptions: confirm in your installed version whether changing a plan's rate updates subscriptions already created from it, or whether each subscription keeps its own copy of the rate.
- Price increases: plan a dated change, with a new plan or an updated rate, and record which customers move and when.
- Test before go-live: create one subscription per plan, run the invoice generation for one interval, and compare the invoice total to the contract amount.
- Taxes: check that the tax template attached to the plan or the customer produces the expected tax on the generated invoice.
Before go-live, confirm with a sample subscription exactly what happens to existing records when a plan's rate changes.
A price list rate takes the amount from an Item Price record for the selected price list at the time invoices are generated. Several customers can share one price list, and the sales team or pricing owner can update rates in one place without editing each subscription. This suits organizations with tiered customers, regional pricing or frequent rate reviews. The cost is that the billed amount now depends on a second record, so a missing or outdated Item Price can change what gets billed without anyone editing the subscription.
- Ownership: the pricing owner maintains the price list, and billing or finance should review changes before they take effect.
- Change flow: confirm in your installed version when the rate is read, at subscription creation, at each invoice, or both, since that determines whether a price list update reaches existing subscriptions.
- Missing rates: test what happens when an item has no Item Price for the subscriber's price list, and make sure the failure is visible rather than silent.
- Currency and dates: check how price lists with different currencies and validity periods behave for active subscriptions.
- Test before go-live: change a rate in a test price list, generate invoices for affected subscriptions, and confirm the amounts match the intended change.
Before go-live, document which price list each customer group uses and who approves any change to it.
Proration charges only the part of a period that a customer actually uses when a subscription starts mid-period, changes plan or ends early. Without it, customers either pay for days they did not receive or the organization absorbs the difference manually. Proration logic involves day counts, rounding, tax and the point at which the change takes effect, so it is the part of pricing most likely to produce disputed invoices. Treat it as a separate design decision, not a default that comes with the plan.
- Ownership: the billing owner decides the proration rule, and finance signs off on how partial periods are rounded and taxed.
- Behavior to confirm: verify in your installed version whether proration is supported for mid-period starts, plan changes and cancellations, and how it counts days.
- Rounding and tax: test the rounding of partial amounts and whether tax is calculated on the prorated figure.
- Changes mid-cycle: decide whether an upgrade takes effect immediately with a credit, or at the next invoice date.
- Test before go-live: run scenarios for a mid-month start, an upgrade, a downgrade and an early cancellation, and reconcile each result to a hand calculation.
Before go-live, obtain written confirmation from your own test results of how each proration scenario behaves in the version you install.
The three approaches are often combined. A common pattern is a price list for negotiated rates, with a fixed plan for simple self-contained offers and proration enabled only for plans where mid-period changes are common. The right mix depends on how often prices change, how many customer groups you bill, and how much your team wants to trace each amount to a single record. Illustrative example: a hosting provider with three standard tiers and a few negotiated enterprise contracts might keep standard tiers on fixed plans and move enterprise customers to a price list.
- Change frequency: frequent rate reviews favor price lists, while stable offers suit fixed rates.
- Customer segments: separate price lists per segment make tiered pricing visible in one place.
- Audit trail: a fixed rate is easiest to trace on one record, while a price list requires a check of both the plan and the rate table.
- Mid-period changes: if upgrades and cancellations are frequent, decide on proration before choosing the plan structure.
- Quote scope: ask any implementation partner to list the pricing approaches it will configure, the test scenarios it will run and what each one requires your team to maintain.
Before committing to a model, write down who changes each rate, how the change reaches existing subscriptions and which test proves it.
Subscription configuration options and when each fits
This table compares the main Subscription settings in ERPNext, what each one controls, when it fits a recurring business and what to check before you rely on it. Read each row against your contracts and your accounting close, because several settings change when invoices are raised and how revenue is booked. The main takeaway is that timing, tax and renewal rules are easier to set correctly before the first invoice than to correct afterward.
| Option | What it controls | When it fits | Trade-off to check |
|---|---|---|---|
| Fixed pricing | Each billing cycle charges the same plan amount set on the Subscription Plan | Flat-rate services such as support contracts or standard memberships | Mid-cycle changes need a plan change or proration rule, so confirm how upgrades are handled |
| Price list pricing | Plan amount is taken from the selected price list at each billing run | Customers on negotiated or regional price lists that may change over time | Confirm which price list applies to each customer and what happens when a list is updated |
| Prorated pricing | Partial-period charges when a subscription starts, changes or ends mid-cycle | Contracts that start or stop on arbitrary dates or allow mid-term upgrades | Test proration against your contract wording and your revenue schedule before go-live |
| Billing interval | How often the subscription generates invoices for the customer | Monthly, quarterly, yearly or custom cycles that match the contract terms | Check that the interval, invoice timing and customer payment terms agree with each other |
| Invoice timing (start of period) | Invoices are raised at the beginning of the period they cover | Prepaid services where cash is collected in advance | Deferred revenue handling and period close must be designed with your accountants |
| Invoice timing (end of period) | Invoices are raised after the period has been served | Usage-based or arrears billing where the amount depends on what was delivered | Customers may question invoices later, and collections start later |
| Tax templates | Which tax rates and accounts apply to each generated invoice | Customers in different tax jurisdictions or with exemption certificates | Verify tax templates with your tax advisor, since ERPNext applies what is configured and does not decide liability |
| Discounts | Reductions applied to the plan amount, often at customer or plan level | Negotiated renewals, multi-year commitments or promotional first periods | Confirm whether a discount applies to every future invoice or only to the first cycles |
| Cancellation and renewal | How a subscription ends, pauses or renews at the end of its term | Contracts with fixed terms, automatic renewal or notice periods | Test cancellation and renewal with real contract dates, including the handling of already generated invoices |
| Supplier subscriptions | Recurring purchase invoices for vendors such as software licenses or hosting | Recurring costs you pay on a schedule, such as leases, support or SaaS seats | Check how the supplier invoice is approved and paid, since it does not collect payment from customers |
Setting up a Subscription Plan and first subscription
This sequence moves a recurring billing setup from verified accounting foundations to a Subscription Plan, a tested subscription, and a production switch-over that only happens after the generated invoices and ledger postings have been checked. Each step closes with a check the team can run before moving on.
Confirm company, accounts and tax foundations
Before any subscription exists, confirm the company record, default receivable and payable accounts, income and expense accounts, and the tax templates that recurring invoices will use. Ask your finance lead to sign off the chart of accounts and the tax treatment for each product or service that will be billed on a schedule. Done means a test sales invoice created by hand posts to the expected accounts and shows the expected tax lines, so you know the defaults the subscription will inherit are correct.
Build price lists and item prices
Set up the price lists that the Subscription Plan will reference, and confirm each item carries the right selling or buying rate in the currency the customer or supplier is billed in. Agree with the business who owns each price list, because a later change to a list affects every subscription that points to it. Done means you can open each item and see the rate for each price list that will be used in billing, with no missing currencies.
Create the Subscription Plan
In the Subscription Plan DocType, define the plan name, the item or items it bills, the billing interval and billing count, and the pricing basis: a fixed price, a price list rate, or a prorated amount. Decide how the plan treats taxes and discounts at this stage, and record the currency. Done means the plan saves with the intended interval and price, and a preview or test of its amount matches the figure agreed in your written scope.
Attach the plan to a customer or supplier subscription
Create a Subscription for one customer (or, for purchases, one supplier) and select the plan, start date, and party details. Set the invoice timing and whether the subscription starts with an invoice in the first period. Confirm the party's default tax template and any party-level discount override. Done means the subscription shows the expected next billing date and the expected first invoice amount in its preview before anything is generated.
Run a test billing cycle in staging
Copy the configured accounts, tax templates, price lists, Subscription Plan and a sample subscription to a staging site, then run the scheduled process manually or advance the subscription's billing date so it generates an invoice. Use a test customer and a test supplier if you are covering both directions. Done means the staging site produces the invoice you expected on the expected date, and nothing reaches a real customer email or payment gateway.
Verify invoices, taxes and ledger postings
Open the generated invoice and check the line items, quantities, rates, discounts, tax lines, totals and the posting date. Then open the General Ledger and Accounts Receivable (or Payable) reports and confirm that each amount lands in the accounts your finance lead approved, with taxes in the correct liability or receivable accounts. Repeat for a proration case and a discount case if your plan uses them. Done means every test invoice reconciles to the expected ledger entries, and any difference is traced and fixed before production.
Enable production billing and monitor the first cycle
Move the validated configuration to production, using the same configuration steps rather than copying test records. Start production subscriptions in a small batch, then check the first generated invoices against the staging results and the finance team's expectations. Confirm who receives notifications for failed or overdue invoices. Done means the first real cycle produces invoices that match the staging checks, and the finance team has signed off the ledger view for that cycle.
When ERPNext subscriptions fit better than Stripe subscriptions
The decision comes down to where the customer's card and the dunning process live. Running recurring billing inside ERPNext keeps the Subscription, the generated sales invoices, the revenue schedule and the receivable in one ledger, so the finance team closes the month against a single source. A payment provider's subscription product takes over card capture, retries of failed charges, payment-method updates and, depending on its setup, the customer-facing billing portal. Before choosing, map each of these functions on paper: who collects the money, who chases a failed payment, who the customer contacts to change a plan, and which system holds the tax calculation for each invoice. Whatever moves to the provider leaves the ERP, and the reconciliation work moves with it.
ERPNext fits best when most customers pay by invoice or bank transfer, when you bill suppliers on a recurring basis, or when your tax obligations depend on rules you already configure in ERPNext, such as tax templates and accounting dimensions. Stripe-style products fit better when card payment at the point of renewal is the core of the business, when customers expect self-service plan changes and card updates, and when your team does not want to build and operate retry logic. Many organizations split the work: the provider collects card payments and sends payment events back, while ERPNext keeps the subscription terms, invoices and ledger postings. Confirm the exact connector behavior, including which documents it creates, how it maps taxes and how it reports failed payments, in the integration documentation for your ERPNext version before you commit to a design.
Security and operational risks in recurring billing
Recurring billing fails quietly. A plan edit nobody reviewed, a scheduler job that stopped running, or a restored database that reissues invoices can all reach customers before anyone notices. The cards below cover the access, audit, scheduling, restore and data-handling checks to settle before subscriptions go live.
Restrict who edits plans and prices
Subscription Plans and the prices they reference determine every future invoice, so edit rights on them are a financial control. Limit create and edit permissions on Subscription Plans and Price Lists to a small finance group, and separate the people who set prices from those who approve subscriptions. Check role permissions on the Subscription DocType as well, because a user who can change a linked plan can change what a customer is billed without touching the customer record.
Audit changes to amended subscriptions
A subscription that is amended mid-cycle can change quantities, plans or dates while earlier invoices still reflect the old terms. Review who amended each subscription, when, and what changed, and confirm that the version history is retained in your ERPNext instance. Ask your team to define a rule for how price changes reach existing customers, so a finance reviewer can reconcile a customer's billed amount against the agreed contract at any point.
Catch failed scheduler and background jobs
Subscription invoices are generated by scheduled background jobs, so a stopped worker or disabled scheduler produces missed invoices without an error on screen. Monitor the scheduler and background queues as a routine operational task, with alerts on failed jobs and a daily check that expected invoices were created. Record who owns that check and what happens when an invoice run fails, because a late catch-up run can send several billing periods at once.
Prevent duplicate billing after restores
Restoring a site from backup can bring back subscriptions whose invoices were already generated after the backup was taken, so the scheduler may bill the same period twice. Before re-enabling the scheduler on a restored site, compare the last generated invoice date on each subscription with the live system, and pause scheduled processing until the comparison is done. Include this step in your restore runbook and test it on a copy before you need it.
Keep payment and card data out of ERPNext
ERPNext records subscription invoices, customer contacts and payment references, but it should not hold full card numbers, card security codes or bank login credentials. Where card payments are taken, use a payment gateway that tokenizes the card and store only the reference that ERPNext needs to match a payment. Confirm with your security and compliance leads which systems fall within scope for card data, and document that boundary before connecting a gateway to subscriptions.
What does it cost to automate subscriptions in ERPNext?
How much does it cost to set up subscriptions in ERPNext?
The cost depends on the written scope, not on a list price, and DeployOpen does not publish one. The software itself is not the main line item: ERPNext is free and open source, and the pricing page states that self-hosting ERPNext is free. What you pay for is the work: configuring Subscription Plans, mapping them to your price lists and tax templates, testing invoice runs and training finance staff. Ask for the quote to break these into separate lines so you can see which parts are one-time and which recur.
How long does subscription configuration usually take?
Duration follows from the number of plan types, billing intervals, tax rules and integrations in scope, and no duration figure is supplied for this work. A single fixed-price monthly plan with standard taxes is a small exercise. Prorated pricing, several price lists, multi-currency invoices or supplier subscriptions add design and test cycles. Ask the vendor for a phased plan with a named milestone for each plan type, and confirm which items are blocked by decisions your finance team has not yet made, such as invoice timing and proration rules.
What do our finance and IT teams need to provide?
Finance owns the commercial rules, and IT owns the environment and access. Finance should supply the customer price lists, billing intervals, proration policy, discount rules, tax treatment per customer group and the approvers for any manual change. IT should provide a non-production ERPNext site, the account and role model for who can create and cancel subscriptions, and the rights to run scheduled jobs. Without these inputs, configuration stalls, and test invoices often reveal rules that were never written down.
Can our team configure ERPNext subscriptions without a partner?
A capable ERPNext team can configure simple subscriptions alone, using the Subscription Plan and Subscription documentation and a test site. The risk rises with pricing complexity, tax edge cases, integrations with payment or bank systems and the number of billing cycles you must validate before go-live. Decide early which parts your staff will own after handover. Ask any partner to document what was configured, why, and which tests proved it, so your team can maintain the setup without the original builder.
What makes subscription costs go up or down?
Four factors move the effort most:
- Pricing complexity: fixed, price list and prorated plans, plus upgrades and downgrades mid-cycle, each need separate rules and tests.
- Tax rules: multiple tax templates, exemptions or regional rules increase review time and the number of invoice scenarios.
- Integrations: a connection to a payment gateway, bank feed or Stripe changes which system is the source of truth for payment status.
- Testing volume: the number of plan variants, customer groups and billing intervals determines how many invoice cycles you must simulate before the first live run.
Reducing any of these, such as standardizing plans, lowers both build and test cost.
What should we ask for in a written quote for subscription work?
Ask for a fixed scope statement that lists each Subscription Plan type, billing interval, tax treatment, discount rule and supplier subscription included. Request the deliverables (configured plans, test records, runbook and training), the assumptions about your data and approvals, the items excluded, and the acceptance criteria. Also ask who runs the first live billing cycle and how changes after go-live are priced. A quote without these items is hard to compare with an internal estimate or another bid.
How does ongoing support fit alongside the one-time build?
The build is typically one-time, while support, upgrades and changes recur. ERPNext releases frequent minor versions on both supported major lines, and Frappe's supported versions policy requires a listed version and a matching support plan for warranty coverage, so plan for regular patching. DeployOpen offers ongoing support and upgrades as retainers. Ask what the retainer covers, how tax or price changes are handled, and how quickly a failed billing run is investigated. Confirm response expectations in writing rather than assuming them.
How DeployOpen works on this
DeployOpen plans, implements, customizes, integrates, documents and supports ERPNext inside your own infrastructure, including the Subscription Plans, invoice timing and tax setup that recurring billing depends on. Engagements are fixed-scope, with the billing rules agreed in writing before any configuration starts.
How we scope
- Written scope lists each billing model, plan type and interval the business needs in ERPNext.
- Scope records how prorated pricing, discounts and taxes apply to each subscription plan.
- Scope names the supplier subscriptions, Stripe connections and data sources in or out of scope.
How we build
- Subscription Plans, price lists and invoice timing are configured and tested against sample customers.
- Custom server scripts and apps are added only where standard subscription settings fall short.
- Test cases cover renewals, cancellations, mid-cycle changes, credit notes and tax on each invoice.
How we hand over
- Deliverables include configuration records, test results and a written runbook for finance staff.
- Documentation explains who approves plan changes, how invoices are checked and when to escalate.
- Handover sessions walk finance and administrators through month-end checks on recurring invoices.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover ERPNext version upgrades, including checks on subscription behavior after each release.
- Confirm with DeployOpen the response expectations and the ticket process before the retainer begins.
