EspoCRM sales pipeline and forecast reports

How EspoCRM sales pipeline reports answer the forecast question

A sales leader who needs opportunities by stage, owner and month is asking a reporting question, and in EspoCRM that question is answered by the Advanced Pack, an official add-on that provides reports and is included in all EspoCRM Cloud plans. Self-hosted deployments need the Advanced Pack installed as an extension, so confirm its licensing and availability for your edition before you commit to a report-based design. Each report type answers a different part of the forecast question, and the choice between them should follow from the questions your managers actually ask each week.

A *grid report* groups opportunities into rows and columns, for example stage down the side and close month across the top, with totals in each cell. It is the right starting point for a pipeline view by stage and period. A *list report* returns the individual records behind a figure, which managers need when they want to inspect the deals inside a total. A *joint grid report* combines two grid-style result sets so that, for example, bookings by owner can sit beside sales targets for the same owner and period. Dashboard charts then present the outputs of these reports to each role. Confirm in the docs for your EspoCRM version which grouping, aggregation and chart options are available, since report features change between releases.

Before building any of these, decide which definition of pipeline each report will use, which stage values count as open, and who sets the targets that a joint grid compares against. Those decisions shape the reports more than the layout does. Check the report permissions for each role as well, because a manager who sees a total may not be able to open the records behind it. Test every report with a small set of known opportunities and confirm the totals before any manager relies on them for a forecast call.

Which report type fits each pipeline question

This table compares list reports, grid reports, joint grid reports and dashboard charts against common pipeline and forecast questions. Use it to choose the simplest report that answers the question, then confirm the exact grouping and filter options in your EspoCRM version before you commit to a design.

Question	Report type	Data shape returned	Main trade-off
Which named opportunities close this month?	List report	One row per opportunity with chosen fields	Full detail for follow-up, but no totals or grouping to scan the pipeline
Pipeline value by stage and owner	Grid report	Rows and columns grouped on two fields with totals	Compact summary for managers, but it shows one grouping view at a time
Pipeline by stage and close month	Grid report	Matrix of stage against close month, with aggregated amounts	Good for trend reading, but wide grids are harder to read when many months are shown
Actual against target by owner and month	Joint grid report	Two grids combined on shared row keys, such as owner and month	Enables comparison, but both source reports must share keys that line up
Forecast trend at a glance for leadership	Dashboard chart	Visual series or bars built from a saved report or grid	Fast to read, but hides the records behind the number and needs careful labeling
Open deals that need action this week	List report used as a list view filter	Filtered records shown inside everyday screens	Keeps users in context, but access depends on the role permissions behind the report
Currency-mixed pipeline totals	Grid report with currency handling	Totals that depend on how amounts are converted or grouped	Mixed currencies can distort sums, so confirm how your version converts and labels amounts

How the opportunity data model shapes the report

A pipeline report is only as reliable as the opportunity fields behind it, so the field definitions should be settled before anyone builds a grid. Decide what stage means in your sales process, whether amount is stored in one currency or the deal currency, which date is the close date the forecast uses, who the owner is when a deal changes hands, and which team a deal belongs to for roll-ups. Each of these becomes a grouping or aggregation axis in the report, so an ambiguous definition shows up as a wrong total rather than an error message. Write the definitions down, including who may change a stage and what happens to the close date when a deal slips.

Derived values such as a weighted amount or a month bucket are best prepared once on the record rather than rebuilt inside every report. Formula Script, EspoCRM's built-in scripting language, can run in a before-save script configured in the Entity Manager, so the value is stored whenever the opportunity is saved. A weighted amount can multiply the amount by a probability taken from the stage, and a month bucket can derive a month from the close date. The same formula language is used in workflows and BPM, so a stage change that updates a derived field can be handled in one consistent syntax. Confirm the exact functions and field names against the EspoCRM formula documentation for your version before writing any logic.

Before building the report, test the derived fields on a small set of sample opportunities across several currencies, months and owners, and check that the stored values match what a finance reviewer expects. Record the decisions in a short field specification that names each field, its type, its allowed values and the formula that populates it. Changing a stored field later means migrating existing records, so treat the specification as a gate that the report design must pass. Ask your implementation partner, or your own team, to confirm how historical opportunities will be backfilled before the first report is shared.

Setting up the opportunity pipeline report step by step

This sequence takes a team from an EspoCRM instance with the Advanced Pack enabled to a checked set of pipeline reports by stage, owner and month, with a joint grid comparing results against targets. Each step ends with a reconciliation so the numbers can be trusted before managers rely on them. Effort depends on data quality and the number of stages and teams.

Confirm the Advanced Pack and report access
Confirm that the Advanced Pack is enabled on the instance and that the administrator and the report authors have the role permissions to create reports on Opportunity records. The Advanced Pack is included in all EspoCRM Cloud plans, so cloud customers should check their plan, while self-hosted instances need the extension installed and licensed separately. Confirm with your administrator that the Reports menu appears for a test user with the intended role. The step is done when a test report can be created and run against Opportunity records without a permission error.
Define opportunity fields and stages
Agree with sales leadership which stages count as open, won and lost, and what amount and close date mean for each opportunity. Check the Opportunity entity in the Entity Manager for the stage field options, the amount field and its currency field, the close date field, and the owner and team fields used for assignment. Remove or rename stages that no longer reflect the sales process, because report groupings inherit those values. The step is done when a written field and stage definition is signed off and matches the picklist values in the instance.
Build the grid report by stage, owner and month
Create a grid report on Opportunity with stage as the row grouping, owner as the column grouping, and a month grouping on close date. Set the measure to the sum of amount and, if you use multiple currencies, decide whether to report in the original currency or a converted one before adding the measure. Keep the first version narrow so the structure is easy to check. The step is done when the grid runs without error and each row total matches the number of records in the underlying filter.
Reconcile the grid against a list view
Open a list view of Opportunities filtered to the same stage, owner and close date range that the grid uses, and compare the record count and the sum of amounts with the matching grid cell. Investigate any difference, which usually comes from blank close dates, records outside the period, opportunities owned by inactive users, or currency conversion. Record the reconciliation in your build notes. The step is done when at least one cell per stage matches the list view exactly, and every remaining difference has a named cause.
Add team and period filters
Add filter fields to the report for team and for a date period, such as a close date range set by the viewer. Test each filter with a user from each team, because team visibility in EspoCRM follows the role and team setup and a report can show a total that a user is not allowed to see record by record. Confirm the filter defaults with the managers who will read the report. The step is done when each filter changes the totals as expected and a user from one team cannot see records owned by another team through the report.
Build the joint grid comparison against targets
Create a target dataset that holds one target per owner or team and period, then build a joint grid report that places the actual opportunity totals beside the target totals on a shared owner and month axis. Agree with finance whether the target is an amount for won deals, for weighted pipeline, or for all open pipeline, and label the measure clearly. The step is done when the joint grid shows actual and target values side by side and the variance is calculated for a sample owner that a finance reviewer has checked by hand.
Verify currency handling and edge cases
Test the report with records in every currency in use, with records that have no amount, and with opportunities moved between stages in the same period. Check how the currency conversion rates in the instance are applied and confirm the rates with your finance team, because EspoCRM reports do not replace accounting rules. Check that the totals for won and lost stages do not leak into open pipeline. The step is done when the edge-case records appear in the expected row and column, and the finance reviewer signs off on the currency basis in writing.
Confirm the report is ready for dashboards and schedules
Save the final reports with names and descriptions that managers can understand, and confirm which reports will appear on dashboards or be sent on a schedule. Run each saved report as a manager user and compare the output with the reconciled version from the earlier step. Document the report owner and the person who approves changes to stages or the target dataset. The step is done when every saved report runs for each intended viewer role, returns the reconciled totals, and has a named owner.

Currency handling choices for multi-currency pipelines

When every opportunity is recorded in the same currency, a grid report sums the amount field directly. A grid grouped by stage, owner and month totals the amount for each group, so the figures are only as reliable as the data entered. This is the simplest setup to run and verify, and the other two models build on it.

Stage and owner totals: Each cell adds the opportunity amounts in its group, so a grid by stage and month gives a direct view of the pipeline.
Single currency check: Confirm that the currency field holds one value across all opportunities, including records created by import or migration.
Legacy records: Look for older opportunities with blank or different currency values, since they can drop out of totals or distort them.
Labeling: Name the report and dashlet with the currency so managers read the totals as recorded amounts.

Before publishing, confirm in the currency settings which currency is the system default for your version and test one month against a manual count of known opportunities.

Forecast decisions that change the report design

Most pipeline reports look right until someone asks what the number includes. The six decisions below determine which fields, filters and grid axes the reports need, so they should be agreed with sales leadership before any report is built.

Weighted or unweighted pipeline

Weighted pipeline multiplies each opportunity amount by a stage probability, while unweighted pipeline sums the raw amounts. Each choice needs a different aggregation in the grid report, and mixing them on one dashboard produces totals that do not reconcile. Ask leadership which probability values each stage carries, who maintains them, and whether the forecast view must show both figures side by side.

Close date or created date

The time basis decides which month an opportunity lands in. Grouping by close date shows when revenue is expected, while grouping by created date shows how much pipeline was generated in a period. Confirm which date sales managers use in weekly reviews, and whether slipped close dates should move the opportunity into a later month in the report.

Where targets are stored

Quota targets can live on users, teams, a custom entity or an external planning file. The storage choice determines whether a joint grid report can place targets next to actual pipeline, and how often targets must be re-entered each period. Confirm who edits targets, whether targets change mid-quarter, and whether finance already holds the authoritative figures.

How won and lost stages are excluded

Reports must agree on which stages count as open, won and lost. A filter that excludes closed stages by name breaks when a stage is renamed or added. Ask sales operations for the full stage list, the exact meaning of each closed stage, and whether lost opportunities should appear in a separate comparison view.

How team roll-ups are defined

A team total can mean opportunities owned by team members, opportunities assigned to the team, or opportunities in a region. Each definition uses a different field and filter, and users who belong to several teams can be counted twice. Confirm the ownership rule, how split opportunities are handled, and whether managers see their own team only or the whole hierarchy.

Who owns the forecast number

The forecast figure a board sees must have one accountable owner, whether that is a sales leader, finance or revenue operations. The owner decides which report is the official version, who may change its filters, and who signs off a figure before it leaves the CRM. Settle this first, because it sets the access and dashboard permissions for every other report.

Questions buyers ask before building pipeline reports

What does a pipeline report build cost and what drives it up?

The cost is mostly the labor to define stages, owners, currency rules and targets, then build and test the reports. EspoCRM itself has no license fee for the open-source edition, according to the EspoCRM pricing page, but the Advanced Pack is needed for grid and joint grid reports and is included in all EspoCRM Cloud plans on that page. Cost rises with the number of pipelines, currencies, forecast categories, and how many roles need their own dashboards. Ask for a fixed-scope quote that lists each report, dashboard and test cycle as a separate line, and state which items recur, such as report maintenance after stage changes.

How long does a first version of pipeline reporting take?

Duration depends mainly on how settled your sales process is, not on EspoCRM configuration. A team with agreed stage names, one currency, and a single target per owner and month can usually reach a first working version faster than a team that is still debating definitions. Multi-currency handling, forecast categories, and data cleanup of opportunity amounts and close dates add time. Ask for a timeline that separates definition workshops, build, user acceptance testing and rollout, and confirm the dependency on your data quality.

What does our team need to provide before the build starts?

Provide written stage definitions with entry criteria, the list of owners and teams that should appear in each report, the currency policy, and the target source for each owner and period. You also need the reporting calendar, such as fiscal months or quarters, and the decision on whether forecast values come from opportunity amounts or a separate field. Without these inputs the reports will reflect assumptions that someone has to revisit later. Ask the implementation partner to confirm each input in writing before any grid report is built.

Can an internal admin build pipeline reports without outside help?

A competent EspoCRM administrator can build simple list and grid reports, and charts for dashboards, after reading the Advanced Pack documentation. Joint grid reports that compare opportunities with targets, currency conversion logic, and access rules for different roles take more experience and testing. The main risk is not the build itself but unverified totals, which can mislead forecast decisions. Decide whether your admin will also own ongoing changes, and whether someone independent will check report totals against source records before managers rely on them.

Do we need the Advanced Pack for pipeline reports?

Yes, for the reporting features described on this page. The EspoCRM Advanced Pack page describes it as the official add-on that provides reports, along with Business Process Management and workflows. The EspoCRM pricing page lists the Advanced Pack as included in all EspoCRM Cloud plans. If you self-host the open-source edition, you must license and install the Advanced Pack separately. Confirm the current licensing terms with EspoCRM before you commit to a design that depends on it.

What recurring work comes after the reports go live?

Recurring work includes updating reports when stages, owners or targets change, reviewing dashboards after EspoCRM upgrades, and checking report totals after data imports or bulk edits. Self-hosted instances also need the server, PHP and database kept within supported versions, and scheduled jobs must keep running for report emails and background updates. Ask whether support is a fixed retainer or billed by request, and who approves changes to stage definitions, since those changes alter historical comparisons.

How do we check that pipeline totals are correct?

Compare each report total against a manual extract from the opportunity list for the same filters, stage, owner and period, before anyone uses the figures. Test currency conversion with a sample of records in each currency, and test edge cases such as opportunities closed on the first or last day of a month. Record the test cases, expected results and sign-off in a document that managers and finance can read. Ask your implementation partner to show this test plan as a deliverable, not an informal check.

Access controls that decide who sees pipeline totals

Pipeline totals are only as private as the access model behind them. The cards below cover the decisions that determine whether a rep, a manager or an integration can read opportunity amounts, and each one needs a test with a non-admin user before the reports go live.

Role and team access to opportunities

EspoCRM combines role permissions with team membership to decide which opportunity records a user can read. A grid report only shows records the running user can already see, so a rep's report can differ from a manager's even when both use the same report definition. Confirm the read scope for opportunities, amounts and owner fields in each role, then run the pipeline report as a rep and as a manager to compare the totals.

Report visibility for managers and reps

Decide which reports are shared with which roles, and whether managers see team-wide forecasts while reps see only their own deals. Report access and record access are separate checks, so a manager may open a report and still see fewer rows than expected. Test the forecast report with one rep account and one manager account, and document the totals each should see.

API users reading report data

Integrations that pull pipeline data should use a dedicated API user with a narrow role, not a person's login. EspoCRM documents API key, HMAC and basic authentication, and describes HMAC as the most secure method and basic authentication as not recommended. Confirm which method your integration uses, and check that the API user cannot read opportunities outside its intended scope.

Admin accounts used for report building

Building reports and dashboards is easier as an administrator, but report results built under an admin account can overstate what a rep sees. The security docs advise against using admin accounts for daily work. Build with an admin account, then verify every report and dashboard panel with a standard user before handing it to managers.

Two-factor authentication and session policy

Managers who export or review pipeline totals are attractive targets, so enforce two-factor authentication and set reasonable auth token lifetimes. If you use OpenID Connect sign-in, note that EspoCRM's own 2FA is not compatible with OIDC, so the identity provider must carry the second factor. Confirm that the policy applies to users with report access, not only to administrators.

IP restrictions for reporting access

Restricting access by IP address limits where pipeline totals can be viewed, which matters for remote sales teams and for the API user. Confirm which networks need access, how VPN and mobile traffic reach the instance, and how exceptions are approved. Test access from an allowed network and from a blocked one before the reports are shared.

What to confirm in your environment before you commit

Before you commit to a pipeline report design, confirm how the EspoCRM version you will run handles five things: grouping and chart options in grid and joint grid reports, currency behavior in reports and dashboard charts, how sales targets are stored and updated, performance on your expected opportunity volume, and whether the fields and Formula Script expressions you plan to use behave as expected. Pipeline reports depend on the Advanced Pack, so confirm grouping options such as stage, owner and close month against the Advanced Pack documentation for your release, not against memory of an earlier version. Treat every answer as a question with one source: the vendor documentation for your exact version, then a test instance loaded with representative data.

Currency and targets deserve the most attention, because errors there are silent. Test an opportunity set that mixes currencies, check whether totals are converted or summed in their original currency, and confirm which exchange rates EspoCRM uses and who maintains them. For targets, decide whether they live in a custom entity, a field on user or team records, or a spreadsheet import, and test how an update to a target changes historical joint grid comparisons. Load a volume close to your production size and time the report and the dashboard refresh, since large opportunity tables are where grouping and background job settings start to matter.

Write each result into the written scope before work starts. DeployOpen plans these checks as named tests with the expected output, the EspoCRM version they were run on and the owner who signs off. A check that cannot be answered from the docs or a test instance should become an open item with a decision date, not an assumption carried into the build. Where a check changes the design, such as moving currency conversion into a formula or replacing a chart with a grid, the change should be agreed before the dashboards are configured.

How DeployOpen scopes and delivers EspoCRM reporting

DeployOpen plans and builds EspoCRM sales pipeline and forecast reports as a written, fixed-scope engagement inside your own infrastructure. We agree the reports, data rules and access model before any build starts, then test, document and hand over the result to the team that will use it.

How we scope

Agree in writing which pipeline, forecast and target reports the engagement covers.
Map opportunity stages, owners, teams and close-date fields to the reports you need.
Confirm currency rules, fiscal calendar and which roles can see which revenue figures.

How we build

Configure grid and joint grid reports on the Advanced Pack, with stage, owner and month groupings.
Set up currency handling and conversion logic, then check totals against sample records.
Build dashboard charts and target comparisons, and test them with each role's account.

How we hand over

Document each report's filters, groupings, data sources and the access it requires.
Run a walkthrough with sales managers and admins so they can edit and extend reports.
Deliver written test results and a list of open items agreed with your team.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Review reports again when EspoCRM versions, extensions or pipeline stages change.
Ask for a written quote based on your agreed scope before any work begins.