EspoCRM Sales Pack subscriptions

Who needs EspoCRM Sales Pack subscriptions for recurring invoicing

Sales Pack subscriptions, available from Sales Pack v4.0, invoice customers on a recurring basis using billing plans, billing periods and subscription templates, and they apply proration when a subscription is updated mid-period. This section is for teams that sell retainers, seats, support plans or memberships and currently raise each renewal invoice by hand or from a spreadsheet, often after checking the CRM for what the customer actually bought. If that is your situation, the question is whether the recurring revenue should live on the customer record in EspoCRM, next to the quotes, contacts and service history that explain it.

Implementation makes sense when the commercial terms of a subscription change often enough that keeping them in a separate billing tool creates drift, when account managers need to see the billing status of a customer without switching systems, or when renewals are tied to sales activity that already runs in the CRM. It is also worth scoping when you need invoices generated from the same product and price structure as your quotes. Before committing, confirm that your product catalog, tax rules and currency needs fit the Sales Pack model, and check how invoices will be delivered and reconciled with your accounting system.

Sales Pack subscriptions are not the right tool for every recurring model. If you need complex usage-based metering, dunning and payment collection workflows handled by a dedicated billing platform, or full general ledger posting, plan for an ERP or specialist billing system instead. Treat the EspoCRM Sales Pack subscriptions documentation as the reference for specific settings and behavior, and confirm with a working test instance which features your version supports before you finalize the design.

What EspoCRM Sales Pack subscriptions do according to the docs

The Sales Pack documents subscriptions as a way to invoice customers on a recurring basis, built from billing plans, billing periods and subscription templates. The cards below cover each documented piece and the scheduled job that moves subscriptions through their life cycle, with one item per card to confirm against the docs before you design your billing process.

Recurring customer invoicing

Subscriptions let the billing team invoice a customer repeatedly without creating each invoice by hand. The subscription record is the place to see what a customer is billed for and when the next charge falls due. Before relying on it, confirm in the Sales Pack documentation which invoice fields and related records are created on each billing run, so finance can reconcile them against its ledger.

Billing plans

A billing plan defines how a subscription is charged, and it is the reusable setting that decides the billing pattern for a group of customers. Finance teams should list their pricing models first, then check whether each model maps to one plan without manual edits. Confirm in the docs which plan settings are required and which are optional.

Billing periods

Billing periods set the interval between charges on a subscription. Choosing the period determines how often invoices are generated and how revenue is spread across time. Confirm which period options the Sales Pack supports and how the first and last period of a subscription are handled, since these edge cases drive most reconciliation questions.

Subscription templates

Subscription templates store a standard set of terms that new subscriptions can copy, so sales staff do not rebuild the same offer for each customer. Templates reduce data entry errors when offers are repeated. Confirm whether changes to a template affect subscriptions already created from it, because that determines how you version pricing.

Proration on updates

When a subscription is changed mid-period, the Sales Pack prorates the update so the customer is charged for the time actually used. This matters for upgrades, downgrades and quantity changes. Confirm in the documentation exactly how proration is calculated and which update types trigger it, and test each case with a sample subscription before go-live.

Control Subscriptions scheduled job

The Control Subscriptions scheduled job governs the life cycle of subscriptions, so it decides when billing actions run and when status changes take effect. If the job does not run, invoices can be delayed or missed. Confirm how the job is scheduled on your server, since EspoCRM relies on cron or a scheduled task for background jobs.

How the Control Subscriptions job moves a subscription through its life cycle

A Sales Pack subscription does not bill itself. Once a subscription is created from a subscription template or set up directly on a customer account, its life cycle is driven by the Control Subscriptions scheduled job, which checks subscriptions and advances them through their billing periods. In plain terms, the sequence is: a subscription is created with its charge and billing period, it runs through each period in turn, and the job handles the transitions that follow from that schedule. The Sales Pack subscriptions documentation describes this job as the mechanism that controls the life cycle, so treat it as the core of how recurring invoicing works in your instance.

That makes the server scheduler a billing dependency, not an administrative detail. EspoCRM requires cron or a scheduled task for background jobs, as set out in the EspoCRM server configuration documentation. If the scheduler stops, the Control Subscriptions job does not run, and billing runs tied to those periods can be missed without any error appearing on the customer record. Before go-live, confirm that the scheduler runs under the same user and PHP environment as your production instance, and set up monitoring that alerts someone when background jobs stop. Plan for this in your operations runbook, not only in the initial build.

Do not rely on general descriptions for the details that matter most. In your own test instance, confirm exactly which subscription events the Control Subscriptions job processes, how often it runs by default in the Sales Pack version you install, and how it behaves when a period boundary falls during a scheduler outage. Check the behavior of a subscription that is changed or ended mid-period, and record the results against your billing calendar. Those details belong to the Sales Pack documentation and the version in use, so they should be verified there and in your environment before you commit to a billing go-live date.

Configuration decisions to settle before building subscriptions

This table compares the main choices you make before configuring Sales Pack subscriptions, with the options, when each fits and what to confirm in the EspoCRM subscription documentation or a test instance. Read it as a checklist: settle each row with finance and sales operations before you create the first billing plan or template.

Decision	Options	When each fits	What to confirm
Billing period	Fixed periods such as monthly or annual, or a single period per template	Monthly suits usage-tolerant offers and lower churn exposure; annual suits prepaid contracts and fewer invoices	Which period values the subscription supports and how the next charge date is calculated
Templates versus per-customer subscriptions	One template per offer, reused across customers, or subscriptions created individually for each customer	Templates fit standard offers with identical terms; individual subscriptions fit negotiated pricing or one-off terms	Whether changes to a template affect existing subscriptions and how overrides are recorded
Mid-term change proration	Prorate on the change date, or apply the change at the next billing period	Proration fits upgrades billed immediately; next-period changes fit downgrades and avoid partial credits	How proration is calculated on updates and the effective date rules in the subscription docs
Invoice and payment setup	Subscription invoices sharing the standard Sales Pack invoice and payment configuration, or a separate numbering and tax setup	Shared setup fits teams with one ledger and one tax regime; separate handling fits multiple entities or currencies	Invoice numbering, tax and currency settings applied to generated subscription invoices
Recurring payment method	Official payment extension such as Stripe, or payments handled outside the CRM	Extension-based collection fits card-on-file billing; external handling fits bank transfers or existing payment systems	Which payment extension version supports recurring charges and how payment status returns to the invoice
Failed or changed billing notices	Advanced Pack workflows that send notices, or a documented manual review process	Workflows fit high volume with consistent wording; manual review fits small books or sensitive accounts	Whether the Advanced Pack workflow triggers on subscription and invoice status changes in your installed version
Scheduled job ownership	Control Subscriptions job run by the system scheduler, monitored by an admin	Any deployment with live subscriptions needs a named owner and a check that the job runs	How the job is scheduled on your server and how failures appear in the logs

How to roll out recurring billing in EspoCRM

This sequence takes a team from a verified platform and Sales Pack version to a live recurring billing run, with a tested plan catalog, scheduled job runbook and a handover the operations owner can follow. Each step closes with a document or test result you can file before moving on.

Confirm platform and Sales Pack versions
On a staging instance, confirm that the EspoCRM version and the installed Sales Pack are both supported together, and that the Sales Pack is v4.0 or later, since subscriptions are not available in earlier releases. Check the server configuration against the EspoCRM server requirements for PHP, database and web server. Record the exact versions in the rollout log. Done means the version record is signed off by the platform owner and matches what production will run.
Verify cron for background jobs
Subscriptions depend on scheduled jobs, so confirm that cron or the equivalent scheduled task runs on every EspoCRM host that will process jobs, and that the job runner executes under the correct user with access to the application files. Trigger a test job and check that it completes in the logs. Done means you hold a dated check record showing the scheduler runs reliably in staging and that the owner of the server knows it is required for billing.
Define products, billing plans and periods
Agree with finance which products are recurring, which billing plans apply to each, and which billing periods and charge timing each plan uses. Document how price changes, taxes and currencies are handled, and who approves a new plan. Load the agreed catalog into staging and review each entry with the business owner. Done means you hold a signed-off plan catalog that lists every product, plan, period and approver.
Build subscription templates
Create subscription templates that map each signed-off plan to the products, quantities and terms a customer receives, using the Sales Pack subscription configuration. Test each template with a sample account and confirm that the generated subscription matches the plan catalog line for line. Name templates consistently so sales staff select the right one. Done means every template passes a review against the catalog and the reviewer has initialled the template list.
Test a full period and a mid-term change
Run test subscriptions through at least one complete billing period using a staging clock or agreed test dates, then confirm that the Control Subscriptions job produces the expected invoices and status changes. Next, make a mid-term change such as a quantity increase or a plan switch, and check the proration result against a manually calculated figure agreed with finance. Record each expected and actual result. Done means the test log shows zero unexplained differences, or each difference has an agreed fix and retest.
Go live with a controlled first run
Move the approved configuration to production through your normal change process, then run the first billing cycle with a small, named set of real subscriptions while finance checks each generated invoice. Watch the job logs during the run and hold a rollback decision point before wider rollout. Write a runbook covering the scheduled job, how to pause subscriptions, who answers billing questions and how errors are escalated. Done means finance has accepted the first invoices, and the runbook has been handed to the operations and finance owners.

What drives the effort and cost of a subscription setup

Subscription work scales with how many offers you sell, how many pricing and proration cases they create, and how tightly billing connects to quotes, invoices and payments. The cards below separate the decisions that move effort up or down from the one-time and recurring costs you should ask a partner to price separately.

Number of offers and billing plans

Each distinct offer usually needs its own subscription template and billing plan, with its own charge amount, billing period and currency handling. Ten offers that differ only by price are cheaper to build than ten offers with different periods and add-ons. Ask the partner to list every offer, its billing period and whether it is sold in more than one currency before estimating build work.

Pricing rules and proration cases

Proration on updates is where most subscription logic gets complicated. Plan changes mid-period, quantity changes, upgrades and downgrades each need a defined outcome, and each outcome needs a test. Write down the rules your finance team already applies by hand, such as whether a change takes effect immediately or at the next billing date, so the design covers them.

Depth of links to quotes, invoices and payments

A subscription that starts from a signed quote, produces invoices in your existing numbering, and records payments against those invoices touches more of the Sales Pack than one that is billed manually. Each link adds mapping, permissions and reconciliation checks. Confirm which records must be created automatically and which your team will still handle by hand.

Custom formula logic and workflow automation

Standard subscription behavior can be extended with Formula Script in before-save scripts, and with workflows in the Advanced Pack for approvals, notifications or handoffs to other teams. Each custom script or workflow needs ownership, documentation and regression testing after upgrades. Ask for a list of every script and automation rule, and whether each one is needed at launch or can follow later.

Load of existing subscriptions

Migrating customers who already pay on a schedule means loading subscription records with correct start dates, next billing dates and amounts. Mismatches here cause duplicate or missed charges, which are costly to unwind. The volume of records, the number of source systems and the quality of the data all change the effort. Ask the partner how they will validate migrated subscriptions against your current billing ledger.

Testing across billing cycles

Subscription defects often appear only after a renewal, a proration or a plan change lands in a later period. Testing therefore needs a timeline of simulated cycles, not a single sample record. Plan test periods that cover monthly and annual renewals, mid-period changes and cancellations. Ask whether test cases will be delivered as a document your team can rerun after upgrades.

What each team must provide during a subscription build

Finance or billing owners decide what the subscription system actually charges. Their inputs define the commercial rules that the build encodes, so they should be settled before anyone configures a billing plan or subscription template. Ask them to produce a written plan catalog and a set of proration rules that a non-developer could follow.

Plan catalog: the products or services that can be subscribed to, their billing periods, and the price basis for each plan.
Proration rules: how a mid-period upgrade, downgrade or cancellation is charged or credited, and who approves any exception.
Invoice requirements: the fields, tax treatment, currency and numbering that a recurring invoice must carry to pass review.
Sign-off: a named approver for the catalog and the proration logic, and a record of what was approved and when.
Test cases: sample customers with expected invoices for a first period, a mid-period change and a cancellation.

Confirm with finance which invoices they must reconcile against and how the output will be audited, since those answers determine the fields and records the build must keep.

How subscriptions connect to the rest of the EspoCRM platform

A subscription does not run alone. It produces quotes and invoices, sits inside automation that reacts to changes, depends on formulas for its logic, and has to fit the way staff sign in and how billing data reaches other systems. Each card below is a connection to plan and verify before the subscription design is final.

Sales Pack quotes and invoices

Subscriptions produce the invoices that customers receive on each billing period, so they sit beside the quotes and orders that created them. Confirm which quote or order fields carry into a subscription, how the billing plan links to the invoice record, and which product and tax data the generated invoices copy. Check these links in the subscriptions documentation for the Sales Pack version you run, since a mismatch here affects every invoice produced.

Advanced Pack workflows for follow-up

Changes to a subscription, such as a plan upgrade, a paused period or a failed charge, usually need a notification or a task for the account owner. Workflows in the Advanced Pack can react to those record changes and assign follow-up work. Confirm that the Advanced Pack is licensed for your deployment, since it is included in EspoCRM Cloud plans but is an add-on for self-hosted instances, and test each trigger against a sample subscription before relying on it.

Formula Script for before-save logic

Formula Script is EspoCRM's built-in scripting language and runs in before-save scripts configured in the Entity Manager, as well as in workflows and BPM. It can enforce rules such as validating a billing date or deriving a field from the plan before a record is saved. Keep these rules in one place where possible, and confirm in the formula documentation for your version which functions and record attributes are available, so that logic does not depend on an assumption about the data model.

Stripe for recurring charges

Invoices raised by a subscription are records, and collecting the money is a separate step. The official Stripe integration is one option to evaluate for recurring card charges, but its behavior with Sales Pack subscription invoices must be confirmed for your version, including how payment status returns to the invoice. Ask the implementation team to show a full test cycle from invoice to paid status before committing to this path, and agree how failed payments are handled.

REST API for external billing sync

If an accounting or billing system must receive invoices or payment status, the REST API can sync that data. Create a dedicated API user with only the roles it needs, and choose the authentication method documented for your version. The API docs describe HMAC as the most secure method and basic authentication as not recommended, so plan the sync around HMAC and confirm which entities and fields the API user can read and write.

OpenID Connect sign-in for staff

Staff who manage subscriptions should sign in through your central identity provider rather than local passwords. EspoCRM supports OpenID Connect sign-in, with optional user creation on first login and mapping of identity provider groups to teams, which can control who sees billing records. Confirm the fallback login method, and note that EspoCRM's own two-factor authentication is not compatible with OIDC, so the identity provider must enforce second factors.

Loading existing recurring customers into subscriptions

Moving active customers out of a spreadsheet or another billing tool is a data migration, and the order of work matters more than the file format. Start by loading accounts, contacts and products through the CSV import, because subscriptions point to those records and a subscription row that references a missing customer or product will fail or land in the wrong place. The EspoCRM import docs offer Create Only, Create and Update, and Update Only modes, field mapping, and duplicate matching on fields you choose, such as an external customer ID or tax number. Pick the matching fields before the load, and decide which mode fits each entity so that a rerun does not create a second copy of every customer.

Whether subscription records themselves can be loaded by CSV, and which linked records must exist first, is not something to assume. Confirm both in the Sales Pack subscriptions documentation and in a test instance before you build the file. Also confirm how billing periods, charge amounts and next billing dates map onto the subscription fields in your version. Large files run through cron as idle jobs, so confirm that the scheduled job runner is working on the target server first. Imports can be reverted, which gives you a way out of a bad batch, but check that the revert covers every record type you loaded.

Run a small pilot batch before the full load. Choose a few customers across different billing periods, currencies and plan types, import them, and compare each subscription against the source system for the next charge date, amount and proration behavior. Confirm that the Control Subscriptions job picks them up as expected and does not generate a duplicate invoice for the current period. Only after the pilot matches should you load the full set, and keep the old billing tool running in parallel until one full billing cycle has been reconciled. Ask any implementation partner to write this cutover checklist into the fixed scope.

Questions teams ask before building EspoCRM subscriptions

What does it cost to build EspoCRM subscriptions for recurring invoicing?

The cost depends on how many billing plans, subscription templates and change rules you need, and on how much of the invoicing flow touches other systems. Each billing plan, template and proration rule is a design decision that must be tested, so the number of them is the main driver. Other drivers are the payment method, any ERP or accounting export, the data you need to migrate from an existing billing tool, and the number of test cycles your finance team requires. Costs split into one-time work (design, configuration, integration, data migration, testing and training) and recurring items (licensing or hosting, upgrades and support). Ask any provider for a quote that lists each billing plan, template, integration and test cycle as separate line items, with the work each one includes.

How long does an EspoCRM subscription build take?

Duration depends on the number of offers, the integrations involved and how many test cycles finance and sales need before go-live. A build with a small set of plans and no external payment or accounting links usually moves faster than one that must reconcile invoices with an ERP. Confirm with any provider which phases are included in the written scope (design, configuration, integration, testing, cutover and handover), who signs off each phase, and how long each review cycle is expected to take. Ask for a timeline that is tied to those milestones rather than a single end date.

What does our team need to provide before subscription work starts?

The build depends on decisions that only your business can make. Before work starts, you will usually need to document your billing rules: charge periods, billing periods, how mid-term changes are prorated, what happens on cancellation, and which invoice fields and taxes apply. You also need a named sign-off owner for each rule, administrator access to a staging instance, scheduler access so the Control Subscriptions job can run, and realistic test data such as sample accounts, products and existing subscriptions. Agree these inputs in writing at the start, because missing rules are the most common cause of rework in the test cycle.

Can our own team build EspoCRM subscriptions without a partner?

Yes, if your team has administrator access to EspoCRM, owns the billing rules and can test changes on a non-production instance. Start with the official Sales Pack subscriptions documentation, which describes billing plans, periods, subscription templates, proration on updates and the Control Subscriptions scheduled job. Your team will also need the skills to confirm that scheduled jobs run reliably on your server. A partner is most useful when the rules are complex, when subscriptions must connect to payments or accounting, or when your staff cannot test and document changes in the time available.

Does EspoCRM handle recurring card charges automatically?

Do not assume it does. Subscriptions in the Sales Pack manage invoicing on a recurring schedule, but collecting card payments depends on a separate payment integration and its scope. Before you design the flow, confirm which payment extension or connector you would use, which payment events it supports, how failed charges are recorded and retried, and how refunds and invoice status sync back to the subscription. Check these points against the current extension documentation and your payment provider's terms, and test a failed-payment scenario before go-live.

What happens to subscriptions when EspoCRM is upgraded?

Subscriptions are customizations and scheduled behavior, so they should be treated as part of the upgrade. Before you upgrade, restore a copy of production data to a staging instance, install the target EspoCRM version with the same Sales Pack version, and run the full set of subscription test cases: plan creation, period charges, proration on changes, cancellation and the Control Subscriptions job. Confirm that scheduled jobs still run after the upgrade and that invoices and balances match the expected results. Keep a tested rollback plan and a current backup before upgrading production.

How DeployOpen works on this

DeployOpen scopes EspoCRM Sales Pack subscriptions for recurring invoicing in writing before any build starts, then configures billing plans, subscription templates and the Control Subscriptions job inside infrastructure you control. Engagements are fixed-scope, so the billing rules you agree on are the rules that get tested and handed over.

How we scope

Map every recurring offer to a billing plan, charge type and billing period before configuration starts
Record how proration on mid-term changes should work for upgrades, downgrades and cancellations
Confirm which accounts, invoices and tax settings the subscriptions depend on, including any Sales Pack invoicing setup
Agree the written scope, deliverables and timeline with you before work begins, since engagements are fixed-scope

How we build

Configure subscription templates and billing plans in a staging instance that mirrors your production EspoCRM
Set up the Control Subscriptions scheduled job and confirm the server runs the cron or scheduled task it needs
Test renewals, plan changes and proration with sample accounts covering each billing period you offer
Review the Sales Pack version you run against the subscription documentation before the build is accepted

How we hand over

Deliver a written runbook covering templates, plans, proration rules and the scheduled job's expected behavior
Document each test case with its expected invoice output so your team can repeat the checks after changes
Walk your billing and operations staff through how to pause, amend and end a subscription safely
Hand over administration access with the principle of least privilege applied to billing roles

How we support

Offer ongoing support and upgrades as a retainer if you want DeployOpen to keep billing rules tested over time
Re-run the subscription test cases after each Sales Pack or EspoCRM upgrade before it reaches production
Review scheduled job logs and failed renewals as part of agreed operational checks
Ask for the retainer scope in writing so response expectations and included work are clear before you commit