EspoCRM Sales Pack implementation: when your sales documents belong in the CRM
Your sales documents belong in EspoCRM when the team needs quotes, orders and invoices linked directly to the accounts and opportunities that produced them. If those documents are created in a spreadsheet, a separate billing tool or an ERP and only pasted into the CRM afterwards, reps lose sight of what was sold, what was invoiced and what was paid. The official Sales Pack extension is EspoCRM's answer to that gap. It adds a commercial layer to the CRM rather than a second system of record, and it is installed as an extension on your EspoCRM instance. According to the Sales Pack documentation, the extension covers products and price books, quotes, sales orders, invoices, credit notes, delivery orders, return orders and write-offs. It also covers subscriptions, purchase orders, receipt orders, suppliers, bills and bill credits, inventory management, payments, taxes and tax codes, issuance locking, multi-currency, reports and an API. Read the Sales Pack overview before scoping, because the entity list determines which record types your team will actually use. Teams usually implement the Sales Pack when quoting and invoicing volume grows, when sales and finance disagree on order status, or when the CRM must show revenue and stock against each account. Before you commit, confirm which documents must be locked once issued, which tax rules and currencies apply to your customers, and whether any step, such as fulfillment accounting or general ledger posting, must stay in a system outside EspoCRM. Those answers decide how much of this work is configuration and how much is a separate integration.
What the Sales Pack adds to EspoCRM
The Sales Pack extends EspoCRM from customer records into the documents, fulfilment, billing and stock that follow a deal. The cards below group what its documentation lists, so you can decide which parts your teams need in EspoCRM and which belong in a separate system.
Sales documents and billing
Quotes, sales orders, invoices and credit notes sit on the same customer record as the opportunity that produced them. Confirm how your team issues and numbers each document type, and whether a credit note must reference a specific invoice under your accounting rules. Map the approval steps before build, because the document chain is hard to change once records exist. The document chain is the part to design first.
Fulfilment and returns
Delivery orders, return orders and write-offs record the movement of goods against sales orders. Decide who creates a delivery order, whether it can be partial, and how returned stock is received back. Write-offs need a clear reason set and an owner, since they change stock levels without a sale. Test these flows with real warehouse staff before go-live.
Recurring subscriptions
Subscriptions bill customers on a schedule and are the only Sales Pack area that runs without a new sales order each cycle. Confirm your billing periods, how plan changes are priced, and who owns exceptions. Check how subscription invoices flow into the same tax and currency settings as one-off invoices, so reporting stays consistent.
Suppliers, purchasing and stock
Suppliers, purchase orders, receipt orders, bills, bill credits and inventory management cover the buy side and the stock position. Stock is only as accurate as receiving discipline, so define who posts a receipt and when. Decide early whether EspoCRM will hold your full purchase ledger or only the operational steps, because that choice determines whether an ERP is needed alongside it.
Payments, tax and currency
Payments, taxes, tax codes, issuance locking and multi-currency control how money and tax are recorded on each document. Ask your finance team to supply the tax rules and currencies in writing, and test one invoice per combination before build sign-off. Issuance locking protects finalized documents, so confirm who may unlock one and how corrections are handled.
Reports and API access
The Sales Pack documentation lists reports and an API alongside the transactional modules. Reports show pipeline, sales and stock questions from the same records, and the API lets other systems read or write documents. Confirm which reports your finance and operations teams need, and set API permissions through dedicated API users with narrow roles before any integration goes live.
Which configuration decisions shape the Sales Pack build
This table compares the configuration decisions a team should settle before building the Sales Pack, with the options for each and what it affects later. Read each row as a question to answer with finance, operations and your tax advisor before any records are created. The main takeaway is that product structure, tax setup and issuance locking are hard to undo once invoices and stock movements exist.
| Decision | Options | When each fits and what it affects |
|---|---|---|
| Product and price book structure | Flat product list with one price per currency, or products grouped by category with several price lists | A flat list suits a small catalog with one price. Several price lists fit distinct customer segments or channels, but they add setup and review work for every product change. |
| Tax codes and rates | One tax code for all sales, or separate codes per jurisdiction and product type | Separate codes are needed when rates differ by region or product. Confirm the rates and rules with your tax advisor, since the Sales Pack stores what you configure and does not decide tax treatment. |
| Currency handling | Single base currency, or multi-currency quotes and invoices with stored exchange rates | Multi-currency fits customers billed in other currencies. Ask finance which rate source and revaluation method they use, because EspoCRM will record the rates you enter. |
| Stock tracking per warehouse | Company-wide stock count, or stock tracked per warehouse with delivery and receipt orders | A single count is simpler for one location. Per-warehouse tracking is needed when stock sits in several places and must move between them, which adds receipt and delivery steps. |
| Issuance locking | Lock documents at issue, or allow edits until a later stage | Lock at issue when invoices must not change after sending. Decide who may unlock a document and how corrections are made, usually through credit notes, before users start working. |
| Invoice issuance point | Issue invoices in EspoCRM, or export sales data to accounting | Issuing in EspoCRM keeps quote-to-invoice history in one place. Exporting fits when the accounting system is the legal ledger, so confirm the export format and reconciliation steps with the accounting team. |
| Need for a full ERP | Sales Pack only, or Sales Pack with an external accounting or ERP system | The Sales Pack covers quoting, orders, invoicing, purchasing and stock. Manufacturing, fixed assets or multi-entity general ledger needs usually point to an ERP, so map these needs before committing. |
How the Sales Pack rollout runs, step by step
The sequence moves from agreed document flow to a tested, cut-over Sales Pack, with each step producing a record that the next one depends on.
Confirm the document flow and approvals
Your sales, finance, operations and purchasing leads map how a lead becomes a quote, a sales order, a delivery, an invoice and a payment, and where approvals sit at each stage. DeployOpen facilitates the workshops and records each handoff, including who can issue credit notes, write off stock and lock issued documents. The output is an approved document map with named owners for every status change. Do not move on until the finance lead has signed off the invoicing and tax handoffs.
Install and verify the extension on a test instance
Install the official Sales Pack on a non-production EspoCRM instance that matches your production version, PHP and database stack, then confirm the core entities appear in the Entity Manager and that the extension's permissions behave as expected for each role. Check the EspoCRM release notes for the version you run before choosing the extension version. The output is a test instance with a short verification log that records the installed versions and any errors found during setup.
Build products, price books, taxes and currencies
Create the product catalog, price books, tax codes and tax rules, and the currencies you invoice in, using the figures your finance team provides. Decide which prices are fixed, which vary by customer segment and how multi-currency rates are maintained and by whom. Test a sample quote in each currency and tax scenario you sell. The output is a reviewed catalog and pricing configuration, signed off by finance, with the test quotes attached.
Configure layouts and Formula Script logic
Adjust the quote, order and invoice layouts so sales staff see only the fields they need, then add Formula Script before-save logic only where the standard behavior falls short, such as derived totals or required fields at a status change. Keep each script small and documented, since every script becomes a maintenance item at upgrade time. The output is a change list of layouts and scripts, each with its purpose and the test case that proves it.
Load master data
Import customers, contacts, suppliers, products and opening stock from the cleaned source files using the EspoCRM import tool, starting with a small sample file to check field mapping and duplicate matching. Run the full load only after the sample reconciles to the source system. Keep the import reports so the load can be reverted if a file fails. The output is a reconciliation report showing record counts and stock totals matched to the source.
Run quote-to-invoice and delivery tests with users
Have real users from sales, warehouse and finance run scripted scenarios end to end: a quote accepted and converted to an order, a partial delivery, a credit note, a return and a payment. Record each result against the document map from step one, and fix defects before retesting the affected scenario. The output is a signed-off test script with pass or fail results, the defect log and the names of the users who accepted each scenario.
Cut over to production
Freeze changes to configuration, run a final master data load and confirm that open quotes and orders from the old process are either closed or migrated. Switch users to the new process, keep the previous system available in read-only form for reference, and assign an owner for issues in the first weeks of use. The output is a cut-over record listing the freeze time, the final reconciliation and the open issue owner.
Loading products, price books and open documents into EspoCRM
Load your product catalogue, customers, suppliers and open quotes or orders into EspoCRM in a fixed sequence: products and tax codes first, then accounts and contacts, then suppliers, then open documents that reference them. EspoCRM's CSV import offers three modes, Create Only, Create and Update, and Update Only, and the choice matters more than the file layout. Use Create Only for the first load of a clean list, and Create and Update for corrections later. Pick duplicate matching fields deliberately, such as product SKU for products or tax ID for accounts, because a match on a loose field like name will merge records that should stay separate. Map every column explicitly in the field mapping step and confirm that numeric and currency fields arrive without stray formatting.
Run a trial import on a copy of about 20 rows in a non-production instance and check the results before the full load. Large files should go through the idle execution option, which relies on cron running in the background, so confirm that the scheduled job is active on your server first. The import log lets you revert imported records, which is your rollback path if a mapping error is found after the fact, so test the revert on the trial batch as well. Keep the source CSV and the exact mapping under version control so the load can be repeated.
Decide which historical invoices stay in the source system before you import anything. Most teams migrate open receivables, recent invoices needed for returns and credit notes, and open orders, and keep older paid invoices in the accounting system with a reference number. Confirm this decision with finance, because the Sales Pack invoice numbering and tax treatment must line up with what the ledger already holds. Opening stock balances should come from a reconciled physical count, signed off by the warehouse and finance, not from the previous system's book quantity. Record the count date so every later stock movement can be traced back to a known starting point.
What drives Sales Pack implementation effort and cost
This table lists the main factors that change how much work a Sales Pack implementation takes and what it costs. Read each row as a question to settle before a quote is accepted: what drives the effort up, and what you can do to keep scope contained. No figures are given here, so ask each partner to price every driver separately in the written scope.
| Driver | Why it changes effort | How to keep it down and what to ask for in a quote |
|---|---|---|
| Product variants and price lists | Each variant, bundle and price list needs data design, import mapping and testing of quote lines and discounts. | Limit go-live to the active catalog and add variants later. Ask for the number of products, variants and price lists in scope, and how imports are validated. |
| Tax regimes and currencies | Each tax code, tax rule and currency pairing affects quote totals, invoices and reports, and needs sign-off from finance. | Start with the regimes you bill in today. Ask for the list of tax codes, the multi-currency rules, and who approves tax configuration. |
| Warehouses and stock locations | Each warehouse adds stock levels, receipt and delivery flows, and reconciliation checks against counts. | Begin with one location per stock pool and add others later. Ask how opening stock is loaded and reconciled. |
| Subscriptions and purchasing scope | Recurring billing and supplier flows add billing plans, proration rules, purchase orders, receipts and bills, each with its own approvals. | Phase subscriptions and purchasing after quotes and invoices work. Ask whether these modules are in the fixed scope or a separate phase. |
| Custom layouts and PDF templates | Quote, order and invoice documents often need legal fields, logos and language variants, each reviewed by the business. | Reuse the standard templates for the first release. Ask for the number of templates, languages and approval steps for each document. |
| Historical data volume | Migrating open quotes, orders, invoices and stock balances requires mapping, cleansing and reconciliation, which grows with record count. | Migrate open items and opening balances, and keep older history in an archive. Ask for record counts by entity and the reconciliation method. |
| Accounting or ERP integration | Posting invoices and stock movements to a ledger needs field mapping, sync rules, error handling and parallel-run testing. | Decide which system owns the general ledger before design starts. Ask who maintains the integration after go-live and how failed syncs are reported. |
When an ERP is still needed alongside EspoCRM
The Sales Pack records quotes, invoices, credit notes, payments and taxes, which covers the commercial side of a sale. It does not replace a general ledger with statutory accounting, period close, and the chart of accounts your auditors and tax authority expect. If your finance team must post journals, reconcile bank accounts and produce statutory statements from the same records, plan for an accounting system of record alongside EspoCRM.
- Journal and close process: Confirm whether period locking, accrual entries and multi-entity consolidation must happen inside the ERP.
- Tax reporting: Compare the Sales Pack tax codes against the filing requirements in each jurisdiction.
- ERPNext licensing: ERPNext is licensed under GPL-3.0 and includes accounting, so it is a candidate for this need. Check the Frappe support versions page for the version you plan to run, since Frappe warranty coverage depends on a listed version and a matching support plan.
- Odoo licensing: Odoo Community is LGPL-3.0, while accounting features in the Enterprise edition require a subscription and Enterprise source is not public.
- Integration point: Decide which system owns the invoice number and the customer master record before any sync is built.
Confirm with your finance lead and external auditor which system must hold the ledger before you map invoice flows.
The Sales Pack handles products and price books, but it is not designed around production planning. Multi-level bills of materials, work orders, routing, shop-floor scheduling and cost roll-ups for manufactured goods belong in a manufacturing module. If you assemble products from components, need to track production lots, or must cost finished goods from raw materials, the sales workflow will need an ERP to receive the orders.
- Multi-level BOMs: Confirm how many levels your products use and whether sub-assemblies are stocked separately.
- Work orders and capacity: Decide whether production scheduling stays in the ERP or in a separate tool.
- ERPNext manufacturing: ERPNext lists manufacturing among its covered areas, so it is a candidate to evaluate against your process map.
- Odoo manufacturing: Check which Odoo plan and edition include the manufacturing app you need, since Odoo's pricing page limits some features to the Custom plan.
- Order handoff: Define which sales order fields the production system needs and who approves changes after release.
Walk through one finished product from quote to shipment with your production planner before selecting a platform.
The Sales Pack includes inventory management, delivery orders, receipt orders and write-offs, which suits sites with clear stock locations and a manageable number of movements. Operations with many warehouses, bin-level picking, carrier integrations, cross-docking or stock reservations across sites usually outgrow that scope. Test the Sales Pack against your busiest warehouse before assuming it covers the whole network.
- Location depth: Count warehouses, bins and transfer routes, and note which ones need real-time stock levels.
- Fulfillment rules: Define allocation priority when several sites can ship the same order.
- ERPNext stock module: ERPNext covers order and inventory management, so it is a candidate for multi-site stock. Confirm the features you need in the current release notes.
- Odoo inventory: Odoo offers inventory as an app, but check whether your needs depend on the Enterprise or Custom plan features.
- Volume and import: Large item masters or transaction loads may need a bulk import approach, since ERPNext documentation advises importing only a few thousand records at a time.
Run a sample week of movements through the Sales Pack in a test instance to see where stock counts diverge.
If your business is mainly quoting, selling subscriptions or services, and shipping a limited catalog from one or two locations, the Sales Pack may cover the whole commercial process inside EspoCRM. In that case a second system adds integration cost and another source of truth. Keep an ERP in the design only when a documented need, such as statutory accounting, appears in the process map.
- Single source of truth: Keep quotes, orders, invoices and stock in one application so sales and finance see the same record.
- Subscriptions and payments: Confirm the billing cycle, proration and payment capture needs are inside the Sales Pack scope.
- Escalation trigger: Write down the events that would require an ERP, such as a new country, a new legal entity or a production line.
- Exit path: Ask how invoices and stock would move to a new system if the trigger occurs, and whether the Sales Pack API can export the records.
- Licensing note: EspoCRM is AGPL-3.0 and free to self-host, so the decision rests on process fit rather than license cost alone.
Compare the Sales Pack feature list against your order-to-cash map and mark every step it does not cover before you choose an ERP.
How the Sales Pack connects to the rest of your stack
The Sales Pack sits on the EspoCRM core, so quotes, orders and invoices depend on the accounts, opportunities and products around them. Each connection below (APIs, payments, reporting, identity and downstream accounting) changes who owns which record, so each one is confirmed during scoping before any build starts.
CRM core records
Accounts, contacts, opportunities and products are the records every Sales Pack document references. Quotes and sales orders inherit their customer, currency and line items from these entities, so the product catalog and price structure should be designed before any document template is built. Check which team owns product data and whether opportunities move to orders through a stage change or a manual action.
EspoCRM REST API
External order, invoice or fulfillment systems read and write Sales Pack records through the REST API. Use dedicated API users with role-based permissions rather than personal accounts, and choose HMAC over basic authentication, which the docs do not recommend. Confirm which entities each external system may create or update, and who handles failed calls.
Payment connectors
Payments are recorded against invoices, and an official Stripe extension may send card or subscription payments back to EspoCRM. Confirm whether your payment provider has an official connector, which invoice states trigger a charge, and how refunds and failed payments are reflected in the payments list. Where no connector fits, plan a manual or API-based payment record process.
Advanced Pack reports and workflows
The Advanced Pack adds reports and Business Process Management workflows that can react to quote approvals, order status changes or overdue invoices. It is included in all EspoCRM Cloud plans, but a self-hosted instance needs its own licensing decision. Confirm which approval steps and reports depend on it before you design the document lifecycle.
OIDC or LDAP sign-in
Sales staff, finance users and API clients need different access to pricing, discounts and invoices, and those rights depend on who signs in. OpenID Connect sign-in can map identity provider groups to EspoCRM teams, while LDAP covers Active Directory and OpenLDAP. Note that EspoCRM's own two-factor authentication is not compatible with OIDC, so confirm where MFA is enforced.
Accounting and ERP handoff
Invoices and payments usually reach the general ledger in an accounting system or ERP. Decide whether exports are CSV files, API pushes or a manual journal, which entity holds the tax codes, and who reconciles the two systems at month end. If stock valuation or manufacturing must sit in the same ledger, confirm early that the Sales Pack covers the need.
Questions buyers ask before implementing the Sales Pack
What does a Sales Pack implementation cost and what drives the price?
The cost depends on the written scope, not on a list price, and DeployOpen does not publish one. The main components are discovery and design of your products, price books, tax rules and document templates, configuration in EspoCRM, any data migration from spreadsheets or another system, integrations with accounting or payment tools, testing, and handover documentation. Some work is one-time, such as the build and migration. Other costs recur, including hosting, your EspoCRM license if you use a cloud plan, and ongoing support or upgrades if you buy a retainer. Costs rise with the number of product lines, tax jurisdictions, currencies, document layouts and systems that must connect. Ask for a quote that lists each deliverable, the client responsibilities, the assumptions about data volume and the items excluded from scope. The open-source edition can be downloaded and self-hosted for free, according to the EspoCRM pricing page, so hosting and license fees are usually a separate line from the build.
How long does a Sales Pack implementation take?
Duration is set by the number of decisions your business must make before anything is built. Expect the timeline to be driven by agreement on products, price books, discount approvals, tax codes, numbering and the approval of quote and invoice templates. Other factors include how clean your existing product and customer data is, how many currencies and tax regimes apply, whether stock must be counted and loaded, and how many integrations are in scope. Testing with real sample documents and a parallel run against your current process usually takes longer than the configuration itself. Fixed-scope engagements have their timeline agreed in writing before work starts, so ask for the milestones, the dependencies on your team and the review cycles included in that plan.
What does the work need from our team?
Your team has to make decisions and approve outputs, so the work depends on named people being available. Typically you need a product owner who can settle catalog structure, price rules and discount policy; finance sign-off on tax codes, invoice numbering, credit note handling, revenue and currency rules; and sales or operations leads who review quote and order flows. You should also provide sample documents such as current quotes, invoices, delivery notes and receipts, plus a sample of product and customer data in its current form. Ask who will own the system after handover, who approves changes to templates and prices, and who can test edge cases such as partial deliveries, returns and currency changes. Gaps in these inputs are one of the most common reasons schedules slip.
Can our team implement the Sales Pack ourselves using the documentation?
A capable team can configure the basics using the official Sales Pack overview, which covers products, prices, quotes, sales orders, invoices, delivery orders, taxes, multi-currency and an API. The harder part is the design work that the documentation does not make for you: deciding how your catalog, tax codes and document flows should map to your business, testing edge cases, and keeping the configuration consistent through upgrades. Self-implementation is most realistic when the process is simple, one currency and tax regime apply, and one or two people can own the project for the duration. Engage a partner when the process crosses finance, stock and integrations, or when you lack internal time to test. Either way, plan a test environment before changing production, since upgrades and extension changes need to be checked first.
Does the Sales Pack replace our accounting software or ERP?
No. The Sales Pack covers quoting, sales orders, invoices, credit notes, purchasing, bills, stock movements and payments inside EspoCRM, which suits sales and light operations work. It is not a general ledger, manufacturing system or full financial close tool. Before implementing, confirm which system will hold the general ledger, statutory reporting, fixed assets, payroll and any production planning, and how invoices and payments will reach that system. If you need full ERP functions such as manufacturing or multi-entity accounting, compare an open-source ERP such as ERPNext, which covers accounting, inventory, manufacturing and projects, or Odoo, whose Community and Enterprise editions differ in features and support. That comparison should be made before the EspoCRM build starts.
Are subscriptions and purchasing included in this implementation?
They are separate pieces of work and should be scoped on their own. The Sales Pack includes subscriptions for recurring billing, with billing plans, templates and proration, and it includes purchasing with suppliers, purchase orders, receipt orders and bills. Each needs its own process decisions. Recurring billing requires agreement on billing periods, proration rules and how changes are handled. Procurement requires approval limits, supplier data, receiving practices and how bills are matched. Because each adds design and testing, ask for them to be listed as optional modules in the quote so you can decide whether to include them in the first release or after the core quote-to-cash flow is live.
What happens to the system after go-live?
Plan for ongoing ownership before go-live. The system needs routine checks, backups, EspoCRM and Sales Pack updates tested in a non-production environment, and changes to prices, tax rules or templates handled through a controlled process. Ask the implementer what documentation and handover they provide, how changes are requested after go-live, and whether a support retainer covers upgrades and continuous testing. DeployOpen plans, implements, documents and supports self-hosted platforms inside your own infrastructure, and ongoing support is available as a retainer. Confirm the support hours, response expectations and upgrade approach in writing rather than assuming them.
How DeployOpen scopes and delivers Sales Pack implementations
DeployOpen plans, builds, documents and supports self-hosted EspoCRM inside your own infrastructure, including the Sales Pack setup for quotes, orders, invoicing and inventory. Engagements start with a written scope that fixes deliverables and timelines before any build work begins.
How we scope
- Map how your team quotes, takes orders, invoices and tracks stock today, and which steps must stay in EspoCRM.
- Agree in writing which products, price books, tax codes, currencies and document types are in the build.
- Record where ERP, accounting or warehouse systems stay outside the scope, and how data will flow to them.
How we build
- Configure products, price books, taxes and multi-currency settings in a test instance before touching production data.
- Build document flows for quotes, sales orders, delivery orders, invoices and payments with the layouts your teams use.
- Test each flow end to end with your sample records, including issuance locking, credit notes and returns, and document the results.
How we hand over
- Deliver written documentation of the configuration, permissions, product data rules and document numbering.
- Run knowledge transfer sessions with the administrators and finance or operations users who will run the system daily.
- Confirm the hosting, backup and access controls with your own team so ownership of the instance is clear after go-live.
How we support
- Support and maintenance are available as a retainer after handover, covering fixes and changes to the configuration.
- Plan extension and EspoCRM version upgrades together with your Sales Pack configuration and any custom code.
- Ask for the support scope, response expectations and change process to be written into the retainer before signing.
