Running EspoCRM Sales Pack purchasing for suppliers and bills
If your team already sells through EspoCRM and wants purchasing and stock in the same system, the Sales Pack extension is the official way to do it. It adds supplier records, purchase orders, receipt orders that feed warehouse stock, bills from suppliers and bill credits, so procurement sits next to the quotes and sales orders it supports. The supplied overview lists these alongside products, prices, quotes, sales orders, invoices, credit notes, delivery and return orders, subscriptions, inventory management, payments, taxes, multi-currency, reports and an API, as described in the EspoCRM Sales Pack overview. Teams usually implement it when they want one record trail from a customer order back to the supplier order that fulfils it, and when they have outgrown spreadsheets for tracking what has been ordered, received and billed.
Before you commit, confirm with the vendor and in a test instance how the extension handles your specific cases: partial receipts, supplier bills that arrive before goods, currency differences between a purchase order and its bill, and how tax is applied on supplier documents. Decide who creates purchase orders, who approves them and who posts receipts, because those roles determine what each person can see and change. Ask whether the Sales Pack API covers the purchasing objects your integrations need. If your organization requires full general ledger posting, fixed asset accounting, manufacturing or multi-site stock valuation, a full ERP may be the better fit, and you should map those requirements before you treat EspoCRM as the procurement system of record.
What the Sales Pack purchasing objects do
The Sales Pack keeps procurement next to the sales records it already holds. Suppliers, purchase orders, receipt orders, bills and bill credits form a chain that links what you buy, what arrives in a warehouse and what you owe. Each card below names one object and what to check before you rely on it.
Suppliers as records
Suppliers are the vendor records that purchase orders and bills point to. Store payment terms, tax handling and contact details here once, so every purchase order inherits the same vendor data. Before go-live, confirm which supplier fields the Sales Pack provides by default and which you must add through the Entity Manager. Decide who may create or edit supplier records, since a vendor master used for payments needs tight control.
Purchase orders
A purchase order records what you have committed to buy from a supplier, at what quantities and prices. It is the commitment document that later receipts and bills are checked against. Confirm how the Sales Pack handles currency, taxes and line-level pricing for your purchase flows. Also confirm whether it routes purchase orders for approval; the overview does not describe approval routing, so test it in a sandbox before you design a control around it.
Receipt orders into warehouses
Receipt orders record goods arriving against a purchase order and place them into a warehouse. They update inventory, so stock levels in EspoCRM reflect what physically arrived rather than what was ordered. Plan how receiving staff will record partial deliveries and returns, and test how receipts interact with the inventory management features before loading live stock. Ask your implementation team to confirm the exact quantity and warehouse behavior in your version.
Bills from suppliers
Bills capture what a supplier invoices you for, which becomes the payable side of procurement. Record each bill against its supplier and, where your process needs it, against the purchase order or receipt it relates to. Confirm whether the Sales Pack compares bill amounts with purchase orders and receipts automatically. The overview does not describe three-way matching, so treat any automated match as something to verify with your own test cases.
Bill credits for supplier corrections
Bill credits record amounts a supplier owes you, such as returned goods, pricing errors or agreed reductions. They keep the payable balance accurate without editing a posted bill. Define with finance who issues a bill credit, how it is linked to the original bill, and how it appears in supplier reporting. Test the full cycle of a bill, a credit and a payment before you rely on the balances.
Reports and when to add an ERP
The Sales Pack includes reports and an API, so procurement data can be read in EspoCRM or exported to other systems. Check that the reports answer your questions about open orders, stock and supplier balances before you build more. Where you need full general ledger posting, detailed costing or production planning, plan for a dedicated ERP and confirm the integration points early.
How a purchase moves from order to bill
A purchase in the Sales Pack runs through a fixed chain of records: a supplier record, a purchase order, a receipt order into a warehouse, and then a bill, with a bill credit if goods go back or the price was wrong. The point to settle before go-live is which link is the source of truth for each fact: the purchase order for what was committed, the receipt order for what physically arrived, and the bill for what the supplier is owed. Each link carries its own status and numbers, so a team that treats the bill as the record of receipt will misstate stock and accruals. Ask for the Sales Pack documentation for the exact fields and status transitions on each document type before you design approval steps around them, because the behavior at each transition is what your controls must rely on.
The links between documents determine what reporting and stock views show. A receipt order that references a purchase order is what lets the team see open quantities, partial deliveries and over-receipts, and a bill that references the purchase order and receipt order is what lets finance match what was ordered, received and invoiced. Confirm in the docs whether receipt quantities update warehouse stock on posting or on a separate step, whether a bill can be created without a receipt, and whether a purchase order can be edited after receipt starts. Those three answers decide whether your three-way match is enforced by the system or depends on a person checking a list.
Bill credits need a rule of their own. For a partial return, confirm whether the credit references the original bill and the returned receipt, whether stock is reversed in the same step, and how currency and tax are carried over when the bill was in a different currency. Run a test with one purchase order, a partial receipt, a priced-wrong bill and a return, then compare the purchase order, warehouse stock, bill totals and tax lines. The test is illustrative but worth doing before any real supplier is loaded, because the links you verify here are the ones an auditor will ask you to reproduce.
Which purchasing setup fits your team
This table compares the main configuration choices for purchasing in the Sales Pack: scope of the process, warehouse count, currency handling and how bills are created. Read each row against your procurement volume, your number of stock locations and how closely finance needs bills to match goods received, then check the trade-off column before you lock the design.
| Choice | Best fit | Trade-off for reporting and stock accuracy | What to confirm first |
|---|---|---|---|
| Purchasing only in the Sales Pack | Small teams that buy a limited range of goods and keep a single set of approvals | Supplier and bill data stays in one system, but cross-functional reporting against sales depends on how records are linked | Which purchase orders and bills finance will sign off inside EspoCRM |
| Shared sales and purchasing process | Businesses where sales forecasts drive buying or where the same products are sold and bought | Products, stock and pricing are shared, so changes affect both sides and need a clear owner for product records | Who owns product master data and whether price changes flow in both directions |
| Single warehouse | One stock location with simple receiving and dispatch | Stock levels are simpler to reconcile, but transfers and location-level counts are not needed | Whether any stock is held at customer sites or with third parties |
| Multiple warehouses | Several sites or locations that hold and move stock independently | Accurate stock per location depends on receipts being booked against the right warehouse every time | How receipts are assigned to locations and who approves inter-site movements |
| Single currency bills | Suppliers all invoice in one currency that matches your base currency | Bill totals and supplier balances are straightforward to report | Whether any supplier invoices in a foreign currency today |
| Multi-currency bills | Buyers who pay suppliers in foreign currencies or hold multi-currency contracts | Each bill needs a consistent exchange basis, so reporting can differ from the bank position if rates are applied at different times | Which exchange rate source finance uses and when rates are set |
| Bills entered manually | Low volume purchasing or supplier invoices that arrive without a matching receipt | Faster to start, but the bill can drift from what was received unless someone checks it against the order | Who enters bills and how mismatches between bill and receipt are reviewed |
| Bills derived from receipts | Higher volume buying where three-way matching of order, receipt and bill is expected | Bill and stock records stay linked, but receiving discipline becomes critical because errors flow into bills | Whether receipt quantities are booked on arrival and how partial deliveries are handled |
How to roll out Sales Pack purchasing
This sequence moves procurement from a spreadsheet or email habit into EspoCRM, one controlled step at a time. Each step produces a written artifact so that the pilot and the wider rollout rest on agreed scope, clean supplier data and tested purchase-to-bill runs.
Confirm scope and map the purchasing process
Procurement, finance and warehouse leads document how a purchase runs today, from requisition and supplier selection through goods receipt and supplier invoice approval. Mark which steps move into EspoCRM, which stay in other systems, and where an ERP or accounting package receives the data. Done means an approved process map with named owners for each handoff and a written list of what is out of scope.
Define supplier and product master data
Agree the fields each supplier record needs, such as legal name, tax identifiers, default currency, payment terms and contacts, and decide who is allowed to create or change them. Map which products are bought, which are sold, and which are both, since Sales Pack keeps product and price data shared across quoting and purchasing. Done means a data dictionary signed by procurement and finance, plus a cleaned sample of suppliers and products ready for import.
Configure entities and layouts in Entity Manager
An administrator confirms the Sales Pack purchasing entities are enabled and then adjusts their layouts, required fields, and any calculated values through the Entity Manager. Keep changes small and record each one so that upgrades and extension updates can be checked later. Done means a test environment where each purchasing screen shows the agreed fields, and a change log that a second person has reviewed.
Set roles, teams and approval rules
Define roles that separate who raises purchase orders, who approves them, who records receipts into a warehouse, and who enters or approves bills. Assign users to teams that match the warehouses and cost centers they work with, and avoid giving administrator accounts to day-to-day buyers. Done means a permissions matrix tested with at least one test user per role, showing that each user can complete their step and nothing beyond it.
Pilot one warehouse with a few suppliers
Run a limited pilot with one warehouse, a small set of suppliers and a defined product range. Process real purchase orders end to end: create, approve, receive into stock, match the supplier bill and, where needed, record a bill credit. Track every exception and check stock levels and supplier balances against the accounting system at the end. Done means a tested purchase-to-bill run with a reconciled stock and payables position, and a list of defects with owners.
Fix defects and confirm integration points
Resolve the pilot defects, then confirm how purchasing data reaches finance and any ERP or accounting tool, whether through the API or scheduled exports. Confirm that the API users used for integrations have narrow permissions and that their credentials are stored securely. Done means a signed-off integration test and a short runbook covering who fixes a failed sync and how.
Extend to more warehouses and suppliers
Add the remaining warehouses, suppliers and product ranges in waves, repeating the pilot checks for each wave before moving on. Train buyers, warehouse staff and approvers on their own screens and keep the process map current as exceptions are found. Done means every in-scope warehouse runs the agreed process, with a documented owner for the master data and a review date set for the next change to the configuration.
Loading suppliers, products and open orders
Clean data and a deliberate cutover decide whether purchasing works on day one. Before any import, prepare separate files for suppliers and products, and decide for each one whether you are creating records for the first time, updating records that already exist, or only refreshing known records. EspoCRM's CSV import offers three modes for this: Create Only, Create and Update, and Update Only. Use Create Only for a first load into an empty instance, Create and Update when you re-send a corrected file, and Update Only when you must change prices or lead times without adding anything. Map each column to a field explicitly, and choose the duplicate matching fields (for example, a supplier code or product SKU) so a re-run does not create second copies. Run a small sample file first and confirm the duplicate rule behaves as you expect.
Open purchase orders and stock counts need a separate decision, because they change balances, not just master data. You can load open orders as records and receive the remaining quantities through receipt orders, or you can keep historical orders in the old system and start EspoCRM with only the open quantities. Whichever you choose, load stock levels from a physical count taken close to the cutover date, and agree who signs off the count. Imports can be reverted, which helps when a file is wrong, but reverting does not replace a check. Ask your implementation partner or internal team to confirm how the Sales Pack links imported orders to inventory in your version, and test one receipt end to end before go-live.
Validate counts before go-live with a reconciliation that a finance or operations owner signs. Compare supplier and product record counts against the source file, compare open purchase order totals and quantities against the old system, and compare stock on hand per warehouse against the physical count. Repeat the check after a full test cycle with a copy of production data, and keep the import files, mapping and reconciliation output as evidence of the cutover. Large files are processed in the background through cron, so confirm that the scheduled job runs and finishes before you start counting results, and plan the cutover window around that run.
What drives purchasing effort and cost
This table compares the factors that raise or lower the effort of setting up supplier, purchase order and bill handling in the Sales Pack. Read each row as a question to answer before asking for a quote, since the same feature set can cost very different amounts depending on these inputs. The main takeaway is that data quality, approval design and migration volume usually move effort more than the licence itself.
| Driver | Effect on effort and cost | What to ask for in a quote |
|---|---|---|
| Number of warehouses | Each stock location adds receipt routing, stock levels and transfer rules to configure and test. Few locations keep setup simple. | Named warehouses, receipt flows per site, and whether stock must be counted per location |
| Currencies and tax rules | Multi-currency purchasing and supplier-specific tax treatment add rate tables, rounding checks and reporting variants. | List of currencies, tax codes per supplier type, and any reverse-charge or withholding cases |
| Approval rules | Spend thresholds, multi-step sign-off and separation of duties usually need workflow or BPM design, which sits in the Advanced Pack rather than the Sales Pack alone. | Written approval matrix by amount, department and supplier category, plus escalation paths |
| Supplier and product data quality | Duplicate suppliers, missing tax IDs or inconsistent product codes slow matching and import. Cleaning this data is often the largest hidden task. | Who owns cleanup, the expected duplicate rate from your current system, and the matching fields to use |
| Accounting integration | Bills and bill credits must reconcile with the general ledger. Export format, account mapping and posting timing each add work and testing. | Target ledger, mapping of purchase accounts, export method, and reconciliation steps with finance |
| Custom formula logic | Formula Script rules for landed cost, price checks or bill validation are quick to add but need test cases and version control as requirements change. | Each rule written out with inputs, outputs and expected results, and who maintains it after go-live |
| Roles and permissions | Separate roles for buyers, receivers and approvers, plus team scoping, require careful design and access testing. | Role matrix naming who creates, receives, approves and pays, and which teams can see which suppliers |
| Migration volume | Open purchase orders, supplier history and open bills take mapping and reconciliation. CSV import supports create, update and revert modes, but large files need scheduled execution. | Record counts by object, cut-over date, what history must move, and the reconciliation report used to sign off |
Controlling who can buy, receive and pay
Purchasing staff create suppliers, raise purchase orders and follow them to receipt. Access for this group is set through roles and teams in EspoCRM, so the role should allow creating and editing supplier and purchase order records for the teams that own buying, while keeping bill and payment entities outside their scope. Assigning users to a purchasing team lets you scope visibility so buyers see the orders they manage rather than the entire procurement history.
- Role scope: grant create and edit on suppliers and purchase orders, and read-only access to products and prices.
- Team scope: limit record visibility to the purchasing team so buyers do not see unrelated supplier data.
- Authentication: require a strong password policy and 2FA for every buyer account, since the security docs recommend both.
- Daily work: buyers should use a named non-admin account, not an administrator account, for day-to-day purchasing.
- Network: where buyers work from fixed offices, consider restricting their access by IP address.
Confirm with your own purchasing process which actions, such as approving spend above a threshold, should be blocked for this role and handed to finance approvers.
Warehouse staff record receipt orders against purchase orders and maintain stock levels. Their permissions should cover receipt and delivery records and inventory, without the ability to change purchase prices, supplier terms or bills. Separating receiving from buying is a common control, because the person who confirms goods arrived should not also be the person who approves paying for them.
- Role scope: allow create and edit on receipt orders and read on purchase orders, with no edit rights on bills or bill credits.
- Team scope: assign warehouse users to a warehouse team so they see stock for their site only.
- Authentication: apply the same password policy and 2FA requirement used for other staff accounts.
- Admin separation: do not grant administrator rights for routine receiving; admin access should stay with a small set of named platform staff.
- Session control: shorten auth token lifetime for shared warehouse terminals, following the security docs.
Check whether your warehouse uses shared devices or kiosks, since those change how you apply session limits and IP restrictions.
Finance approvers review purchase orders, record bills and bill credits, and decide what is paid. This group needs the widest read access to procurement records and the narrowest write access, so that approving spend and posting supplier invoices are controlled actions. A practical split is to let approvers view purchase orders and receipts for matching, while limiting bill creation and changes to a finance team.
- Role scope: allow read on purchase orders and receipts, and create or edit on bills and bill credits for the finance team only.
- Segregation: avoid giving one account both purchase order creation and bill approval, so no single user can order and pay.
- Authentication: require 2FA for approvers; note that EspoCRM's own 2FA is not compatible with OIDC, so confirm the sign-in method your organization uses.
- Accounts: approvers should work from named accounts, not shared administrator logins.
- Recovery: the docs recommend disabling password recovery for admins, which also protects approver accounts from takeover.
Confirm your approval thresholds and matching rules in writing before the roles are built, since EspoCRM enforces what the roles allow but does not define your approval policy for you.
API users are integration accounts, such as a sync from an accounting system or a supplier portal, that read or write procurement records without a person signing in. EspoCRM supports API key, HMAC and basic authentication through dedicated API users with role-based permissions. The docs describe HMAC as the most secure method and basic authentication as not recommended, so HMAC should be the default choice for any procurement integration.
- Dedicated user: create a separate API user per integration, with a role limited to the entities that integration needs.
- Method: choose HMAC authentication; avoid basic authentication for procurement data.
- Scope: grant only the create or read rights the integration requires, and keep bill and payment write access off unless finance has approved it.
- Network: restrict API access to known source addresses using IP restrictions.
- Review: rotate and review API credentials on a set schedule and remove users when an integration is retired.
Before go-live, confirm which HMAC implementation your integrating system supports and test the permissions with a non-production user.
How purchasing connects to the rest of EspoCRM and your systems
Purchasing in the Sales Pack shares products, inventory and supplier records with quoting and sales orders, so decisions made in one area show up in the others. The cards below cover the connections to plan for: sign-in, scripting, reporting, the API and the accounting system that receives bills.
OIDC sign-in with team mapping
EspoCRM supports OpenID Connect sign-in, with optional user creation on first login and mapping of identity provider groups to EspoCRM teams. For purchasing, team membership decides who can see supplier records, purchase orders and bills, so the group mapping is part of the access design. Confirm which identity groups map to purchasing teams before go-live. EspoCRM's own two-factor authentication is not compatible with OIDC, so check how your identity provider handles MFA.
Formula Script in before-save logic
Formula Script is EspoCRM's built-in scripting language and can run in before-save scripts configured in the Entity Manager, API before-save scripts, workflows and BPM. Purchasing teams use it to enforce rules on purchase orders and bills, such as required fields before approval or consistent status values. Keep the logic in a written list so administrators can review each script when the Sales Pack or EspoCRM is upgraded.
Advanced Pack reports and workflows
The Advanced Pack adds reports, Business Process Management and workflows, and it is included in all EspoCRM Cloud plans. Purchasing use cases include routing purchase orders for approval and reporting open orders by supplier. Confirm whether your self-hosted edition will carry the Advanced Pack, since the cloud plan inclusion does not automatically apply to a self-hosted instance, and confirm the licensing terms before you design approvals around it.
Sales Pack API for purchasing data
The Sales Pack includes an API, and the EspoCRM REST API supports API key, HMAC and basic authentication through dedicated API users with role-based permissions. Use a dedicated API user with read access to suppliers and bills when another system needs purchasing data. The docs describe HMAC as the most secure method and basic authentication as not recommended, so plan for HMAC in any integration.
Accounting system receiving bills
EspoCRM holds bills and bill credits, but the general ledger, payment runs and tax reporting often remain in an accounting system. Decide which system is the record of truth for supplier balances before data starts moving. Confirm with your accounting vendor which export format, account codes and tax fields it accepts for bills. Test the export with a small set of real bills before full cutover.
Shared products and inventory
Products, prices and inventory are shared across quotes, sales orders and purchase orders, so a product's stock level affects both sales and procurement. Receipt orders increase stock in warehouses, which in turn affects delivery orders on the sales side. Agree on one product catalog owner and one warehouse structure before purchasing goes live, because changes to shared product records reach both sides of the business.
When a full ERP is the better fit for procurement
The Sales Pack's purchasing functions suit an organization where selling is the main activity and buying supports it. Choose a dedicated ERP instead when procurement sits inside a larger financial and operational model that EspoCRM was never designed to carry. The clearest signals are a need for general ledger ownership, multi-entity consolidation, manufacturing or bills of materials, full three-way matching of purchase orders, receipts and bills before payment, or warehouse operations with bins, picking waves and heavy stock movement. If two or more of these are firm requirements for the next few years, treat EspoCRM as a sales and customer system that feeds an ERP, not as the ERP.
Test the boundary before the build starts. Write down your procurement scope as a checklist and run the same list against the Sales Pack and against a dedicated ERP such as ERPNext or Odoo, both covered elsewhere on this site. Ask each vendor or implementation partner to show, in your own environment, how a purchase order becomes a receipt, how a bill is matched and approved, how a bill credit reverses it, and how the ledger entries land. Confirm which of these steps produce accounting entries inside EspoCRM and which need an export. Also confirm with your finance team who owns the chart of accounts and period close, because that decision often settles the question before any feature comparison does.
Plan for the hybrid case if it applies to you. Many sales-led organizations keep supplier records, purchase orders and light receiving in EspoCRM while the finance system of record stays elsewhere. In that model, decide early which system owns supplier master data, how bill totals and tax codes are transferred, and who reconciles exceptions at month end. Keep the integration design written down, including the identifiers used for suppliers and purchase orders on both sides, so that a later move to a full ERP does not require rebuilding the procurement history.
Questions buyers ask about EspoCRM purchasing
What does the Sales Pack cost on top of EspoCRM?
The Sales Pack is an official extension, and its price must be confirmed with the vendor before you budget for it. The published EspoCRM Cloud prices are per user per month: 15 US dollars on the Basic plan (minimum 3 users), 25 dollars on Enterprise (minimum 5 users) and 69 dollars on Ultimate (minimum 10 users), with the Advanced Pack included in all cloud plans. Those figures do not tell you the Sales Pack cost for a self-hosted instance. The open-source edition can be downloaded and self-hosted for free, so your recurring costs are infrastructure, hosting operations and any services you buy. Ask the vendor for the Sales Pack licensing terms, whether they recur, and whether they change with user count. Ask DeployOpen for a fixed-scope quote covering setup, configuration and data migration, which is separate from licensing.
How long does a purchasing rollout take, and what drives it?
The duration depends on how many suppliers, products and approval steps you need, how clean your supplier and stock data is, and how many systems the purchase orders must connect to. A single team entering orders into a clean product catalog is a much smaller job than a multi-warehouse operation that must match receipts and bills against existing accounting records. The work usually splits into scope and data mapping, configuration of products, suppliers and warehouses, testing of the purchase order to receipt to bill flow, user training and cutover. DeployOpen agrees a timeline in writing as part of a fixed-scope engagement, so ask for a schedule tied to each phase rather than a single end date.
What must our team supply before a partner can start?
Expect to provide a short list of decisions and data before configuration begins:
- A written purchasing process, including who raises orders, who approves them and what limits apply
- Supplier records, product and price lists, tax treatment and currencies
- Warehouse and stock locations, plus the people who confirm receipts
- Sample purchase orders, receipts and bills from your current process, so the flow can be tested with real cases
- Named business owners who can sign off each stage, and access to a test environment
Missing data is the most common reason a purchasing scope grows, so confirm these items in the statement of work.
Can our staff set up purchasing in the Sales Pack without a partner?
Yes, a team with administration skills can configure suppliers, purchase orders, receipt orders and bills using the Sales Pack documentation, provided it has time for testing and a clear process. The harder parts are usually the ones outside the screens: mapping tax and currency rules, agreeing approval logic, checking that stock movements match physical receipts, and setting up the hosting, backups and access controls that run the system. If your team lacks that experience or capacity, a partner can plan the build, configure it and document it so your staff can operate it afterward.
Do bills in the Sales Pack replace our accounting software?
Not by default. The Sales Pack records supplier bills and bill credits as part of purchasing, which lets you track what you owe against purchase orders and receipts. Whether it replaces your accounting software depends on your general ledger, tax reporting, payment runs and statutory requirements. Confirm with your finance team and accountants which records must be posted to the ledger, and whether an export or integration to your accounting system is needed. Check the Sales Pack capabilities directly with the vendor before deciding.
When is a full ERP a better fit than the Sales Pack for purchasing?
Consider a full ERP when purchasing is tied to manufacturing, complex inventory valuation, multi-entity accounting, or detailed general ledger and cost accounting. Also consider it when you need deep supplier management, landed cost allocation or formal procurement controls across several legal entities. The Sales Pack suits teams whose purchasing is linked to sales, stock and customer records inside EspoCRM. Compare both against a written list of required processes, then ask a partner to map that list to each option. For a related option, see ERPNext only as a reference point for the Sales Pack feature set.
How DeployOpen scopes and delivers EspoCRM purchasing
DeployOpen plans, configures, tests and hands over EspoCRM purchasing with the Sales Pack inside your own infrastructure. We start from your procurement process, agree the scope in writing, and deliver a documented, supported setup your team can run.
How we scope
- We map your current supplier onboarding, purchase approval and bill matching steps before choosing configuration.
- We record which purchase orders, receipt orders, bills and bill credits the written scope covers.
- We confirm which accounting, tax and multi-currency rules must stay in an external ledger or ERP.
How we build
- We configure suppliers, purchase orders, receipt orders and bills in a staging instance first.
- We set roles and teams so buyers, warehouse staff and finance approvers see only their own records.
- We test receipt-to-bill flows with sample transactions agreed in the scope before go-live.
How we hand over
- We deliver written configuration records, role matrices and a walkthrough of each purchasing process.
- We document the import steps used for supplier and opening-balance data, including how imports can be reverted.
- We train named administrators on routine supplier, order and bill maintenance tasks.
How we support
- Engagements are fixed-scope, and changes to purchasing rules are agreed in writing before work starts.
- Ongoing support, Sales Pack upgrades and continuous testing are available as a retainer.
- We plan upgrades with you so that Sales Pack and EspoCRM version changes are tested before they reach production.
