Building a Board-Ready Management Report Pack in the Anaplan UX

Every planning team eventually hits the same wall. The model is right, the forecast is agreed, and then someone spends three days copying numbers into PowerPoint so the CFO can present them on Thursday. By the time the deck is printed, a late reforecast has already made page 7 wrong.

Anaplan's Management Reporting capability in the UX exists to close that gap: board-quality pages built directly on live model data, with narrative text, charts, and a print/export path that produces something you would actually hand to an audit committee. It is not the same job as building a planner dashboard, and teams that treat it like one produce reports that are technically live and visually unusable.

This tutorial walks through building a monthly management report pack end to end: the model layer that feeds it, the report page structure, narrative and chart configuration, the export path, and the refresh routine that keeps it honest.

Reporting pages are not dashboards

Before touching the builder, be clear about the difference, because it drives every later decision.

	Board / worksheet page	Management report page
Purpose	Enter, adjust, analyse	Explain and present
Audience	Planners, analysts	Executives, board, external stakeholders
Layout	Responsive, scrolls, resizes	Fixed page size, pixel-placed, paginated
Interaction	Heavy — grids, filters, actions	Light — page selectors, drill for detail
Output	Screen	Screen, PDF, printed pack

A management report page has a fixed canvas. You choose a page size and orientation (landscape 16:9 for screen-first packs, A4/Letter portrait if the output is genuinely printed), and every element sits where you put it. That fixed canvas is the feature: it is what makes page 4 look the same in March as it did in February.

The practical consequence is that anything variable-height — a grid whose row count depends on how many cost centres breached tolerance — is dangerous on a report page. Plan for the maximum, or filter to a fixed top N.

Step 1: build a reporting layer in the model

The most common failure in management reporting is pointing report elements straight at the calculation modules. It works for one cycle and then someone renames a line item.

Build a dedicated reporting module — call it REP01 Management Report Figures — dimensioned by a small, purpose-built Report Line list, Time, and Version. The list holds exactly the lines that appear in the pack: Revenue, Gross Margin, Gross Margin %, Opex, EBITDA, Headcount, Cash. Each line pulls from the source module via a mapping module or a simple SELECT-free lookup.

You get three things from this:

• Stability. Report elements point at a module that only changes when the report changes.
• Presentation control. Formatting, signs, scaling (thousands versus millions) and rounding belong here, not in the calculation engine. Executives should never see -1234567.8912.
• Auditability. One module shows every number in the pack side by side, so a reviewer can tie the deck back to the model without opening five modules.

Add a small set of commentary line items in text format, dimensioned by Report Line and Time — Variance Commentary, Owner, Action. This is what lets the narrative in the pack be maintained by the business in the model, not typed into a slide.

Finally, add a Report Period and Report Version selection module with a single-cell line item each. Report pages should read those selections rather than hard-coding a period, so rolling the pack forward next month is one cell change, not thirty element edits.

Rule of thumb: if a number appears in the board pack, it should exist as a named line item in the reporting module. If you cannot name it, you should not be presenting it.

Step 2: create the report and its page structure

In the UX, create a new app (or use the existing reporting app) and add a Report page type. Give it a name that matches the artefact the business already knows — "Monthly Group Performance Pack", not "Rep_v3_final".

Structure the report as a fixed sequence of pages:

1. Cover — entity, period, version, prepared-on date. Pull all four from the model so it cannot go stale.
2. Executive summary — five to seven KPI cards plus a narrative block.
3. P&L summary — actual, forecast, budget, variance, with a variance bridge chart.
4. Divisional detail — one page per division, or a single page driven by a page selector.
5. Headcount and cost drivers.
6. Cash and working capital.
7. Risks, actions and assumptions — mostly commentary, sourced from the model.
8. Appendix — detail tables that exist to answer the questions the summary provokes.

Duplicating a page and repointing its selector is the fastest way to build the divisional section, but consider whether one page with a division selector is better. A selector keeps the report to eight pages and the maintenance to one layout; a page per division prints as a complete pack without anyone clicking. Printed packs usually win, so if the pack goes to PDF, duplicate.

Step 3: place elements — grids, charts, KPI cards, text

On a report page you add elements from the same library as other pages, but you size and position them explicitly.

Grids. Point at the reporting module, not the source. Turn off anything that reads as "spreadsheet": gridlines can stay, but hide the row and column headers you do not need, set number formatting to the executive scale, and use conditional formatting sparingly — a single amber/red rule for variance beyond tolerance is worth more than a heat map across every cell. Lock the grid to a fixed number of rows by filtering on a boolean Show in Report? line item in the Report Line list. That boolean is your layout contract.

Charts. Waterfall for bridges (budget to forecast, prior year to current), column for period comparison, line for trend, and almost nothing else. A management report is not the place for combination charts with three axes. Set explicit axis titles and turn off legends where the series is obvious from the title.

KPI cards. One number, one comparison, one direction indicator. Source the comparison from the model so "vs budget" means the same thing on every page.

Text and narrative. This is where management reporting earns its keep. Text elements support dynamic references to model cells, so a sentence can read: "Group revenue of {Revenue, Current Period} was {Revenue Var vs Budget %} against budget, driven primarily by {Top Variance Driver}." The numbers update with the model; the sentence structure stays under editorial control. Mix that with a free-text commentary field pulled from the commentary line items and the business writes the story inside Anaplan.

Use images for the logo and any static regulatory footer. Keep the file small — a 4 MB PNG on every page makes the PDF export miserable.

Step 4: get the typography and spacing right

This is the step consultants skip and executives notice.

• Pick two font sizes for body text and stick to them. Three is already too many.
• Align element edges. If two grids sit side by side, their tops must match to the pixel; the builder's alignment guides exist for this.
• Leave whitespace at page margins. Content that runs to the edge looks broken when printed.
• Use one accent colour, ideally the corporate one, and grey for everything else. Red and amber then mean something.
• Put a page number and the period in the footer of every page. Someone will print it and drop it.

Step 5: the export and distribution path

Test the export before you declare the pack finished, not after.

Export to PDF from the report itself and check three things: pagination (nothing clipped at the page boundary), fidelity (charts render at print resolution, not screen), and dynamic text (every reference resolved to a number, no #REF-style placeholders where a cell was blank). Blank source cells are the usual culprit — wrap dynamic references in a reporting-module formula that substitutes a dash for blanks.

For audiences that live in Excel, the Anaplan Excel add-in can serve the same reporting module as a live refreshable range, which is far better than pasting values. For audiences that live in PowerPoint, resist rebuilding the pack there; distribute the PDF and, if the deck must exist, link a small number of exported images rather than retyping figures.

Access matters as much as layout. Report pages respect the model's roles and selective access, so a divisional MD opening the pack sees their division. Verify that by logging in as a test user with that role — reviewing it in the builder's own admin session proves nothing.

Step 6: the monthly refresh routine

A report pack is a process, not an artefact. The routine that keeps it trustworthy:

1. Close the data. Actuals loaded, integration run confirmed, reconciliation check passes.
2. Roll the period. Update the Report Period selection cell. Every page follows.
3. Refresh commentary. Owners fill their commentary line items in a normal worksheet page — with a workflow task if you have Anaplan Workflow in play, so you can see who has and has not written theirs.
4. Review. One reviewer walks the pack on screen against a checklist: does every number tie to the reporting module, does every narrative sentence still make sense, has any grid grown rows.
5. Export and archive. PDF to the document store with the period in the filename. Keep the archive: "what did we tell the board in Q2" is a question that gets asked.
6. Snapshot the version. If the pack must be reproducible, take a model snapshot or hold the reported version in a locked scenario so a later restatement does not silently change history.

Step 7: put it under change control

Report pages are UX structure, which means ALM moves them like any other structural change. Build report changes in DEV, tag a revision, sync to TEST, look at the pages, then sync to PROD. Commentary text lives in production data and stays where it is — one more reason to hold commentary in line items rather than in the page's static text.

Version the report itself too. When the CFO asks for a new page in month seven, keep the old layout available for comparison rather than editing in place and losing the ability to answer "why does this look different from last month".

Common mistakes worth avoiding

• Pointing report elements at calculation modules. One rename and the pack breaks at the worst possible time.
• Variable-height grids. They look fine until the month a division adds four cost centres.
• Narrative typed as static text. It will be wrong within two cycles. Put it in the model.
• Too much on a page. If the executive summary needs a scroll bar, it is not an executive summary.
• No blank-cell handling. Dynamic text with an empty reference is the single most common export embarrassment.
• Skipping the role-based read-through. Selective access issues only appear when you look through the right eyes.

What good looks like

A finished management reporting implementation means the pack is produced by rolling one cell, commentary is written by the people who own the numbers, the PDF is archived within a day of close, and nobody opens PowerPoint. The finance team stops being a rendering service and goes back to analysis — which is the reason the organisation bought a planning platform in the first place.

If your monthly pack is still assembled by hand from an Anaplan export, that is usually a two-to-four-week build to fix, most of it spent agreeing what belongs on each page rather than writing formulas. Our consultants do this work as a fixed-scope engagement — get in touch if you would like to talk through your current pack.