The Report Writer is the tool Acumatica power users reach for when a standard report doesn't quite cut it — and once you understand how it works, it opens up a level of reporting flexibility most users never realise is available.
In Session 2 of the Avanza customer webinar series, consultant Simon Angland walked through the Report Writer in detail — from installation and interface orientation through to data joins, parameters, calculated fields, grouping logic, and some genuinely forward-looking uses involving AI. This blog captures the key lessons from that session.
Watch the full recording here:
Report Writer vs Generic Inquiries — Knowing Which Tool to Use
Both the Report Writer and Generic Inquiries give you access to data in Acumatica, but they serve quite different purposes. Understanding the distinction up front will save you a lot of time.
Generic Inquiries are operational and on-screen — they produce dynamic, filterable lists that users interact with in real time. They're excellent for day-to-day lookups, Excel exports, and driving dashboards. But they don't give you control over layout, pagination, headers, or grouped subtotals.
The Report Writer produces fixed, formatted output — typically PDF. It gives you pixel-perfect control over exactly where every field sits on the page, how groups and subtotals are structured, what the page headers and footers look like, and how the document behaves when emailed. It's the tool to use when you need a printed or distributable document that looks exactly right every time.
Some practical indicators for which to use:
- Use Generic Inquiries when you need an interactive, filterable list — or a live Excel connection via OData.
- Use the Report Writer when you're producing a form or report with a fixed layout — invoices, statements, purchase orders, sales order summaries, and similar documents.
- Use the Report Writer when you need grouped subtotals, running balances, conditional field visibility, or multi-section page layouts.
- Use the Report Writer when the output needs to be emailed automatically with a controlled subject line, body, and recipient logic.
Note: The Report Writer is a power user tool — not something every Acumatica user needs to know. Most organisations should have one or two people trained to handle minor changes to existing reports and forms, with more complex builds handled by a consultant.
Installing the Report Designer
The Report Writer — referred to in Acumatica as the Report Designer — is a Windows desktop application, not a browser-based screen. This surprises some users, but it means it has capabilities that would be difficult to deliver inside a web interface.
To install it:
- Log into Acumatica and search for 'Download' in the top search bar.
- Select Report Designer from the downloads menu — this will download a zip file.
- Scan the zip file with your antivirus before extracting.
- Extract to a permanent folder on your PC and create a desktop shortcut to the Report Designer executable.
You'll also need the Report Designer role assigned by your system administrator. The Customiser role is useful alongside it — it lets you inspect screens to identify the underlying data tables and fields, which is essential when building or modifying reports.
Tip: After each Acumatica upgrade, reinstall the Report Designer. The application itself is updated during upgrades, and running an older version post-upgrade can cause unexpected errors.
Opening and Editing an Existing Report
Rather than building from scratch, most Report Writer work involves editing an existing report or form. Here's the process Simon walked through.
From within Acumatica, open any report from the menu. If you have the Report Designer role, you'll see an 'Edit Report' option in the actions menu. Clicking this downloads an RPS file — a small pointer file that references back to the system, the report name, and your session.
To open the RPS file with the Report Designer the first time, you need to manually associate the file type with the Report Designer executable on your PC. Once that association is set, double-clicking any future RPS file will open it directly in the Report Designer and prompt you to log in.
After logging in, the full report opens in the designer — and you're editing the live version of the report from the server.
Important: When you save changes back to the server using 'Save to Server', you overwrite the live production version of the report. Always create a new version when saving significant changes — Acumatica keeps a version history, and you can reactivate any previous version if needed.
Understanding the Report Designer Interface
The Toolbox
The toolbox sits on the right side of the designer and contains the elements you can drag onto a report. The most commonly used are:
- Text box — the standard field element. Drag onto the report, resize using corner handles, and assign a value from the schema or write an expression.
- Picture box — for logos and images. Best practice is to use the image at its native size to avoid stretching.
- Line — for ruled lines on the report. Set the line weight in the properties panel.
- Sub-report — embeds a separate report within a section, useful for things like production order steps or detailed breakdowns that sit below the main report body.
Fields will turn red if they overlap — keep an eye on this, as overlapping fields produce unexpected output.
The Properties Panel
Clicking any element on the report populates the properties panel with every configurable option for that element. Key properties to know:
- Value — the data field or expression that populates the text box.
- Visibility — a conditional expression that controls whether the field appears at all. Used extensively for conditional display logic.
- Style name — a reference to the report template's style definitions, which control font, size, colour, and alignment centrally.
- Can grow — controls whether the field expands vertically to accommodate long text, or clips it.
- Mail settings — on document-type reports (invoices, sales orders), controls the email subject, body, recipient, and whether an Acumatica email template is used instead.
Clicking in the blank yellow space outside the report canvas gives you access to report-level properties — page size, orientation, margins, and the template report that controls shared styles across the document.
Report Sections
Every report is built around sections, each of which prints at a specific point in the report cycle:
- Page header / page footer — print at the top and bottom of every page.
- Group header / group footer — print at the start and end of each data group (e.g., per customer, per order).
- Detail — the repeating body of the report, one row per data record.
Sections can be suppressed without being deleted — useful when a section exists structurally but should only print under certain conditions. Multiple detail sections can be stacked to handle complex layouts, such as a standard line followed by a notes line.
The Schema Builder — Connecting Your Data
The Schema Builder (accessed via File > Build Schema) is where you define what data the report draws from. It's the equivalent of the data source and join configuration in Generic Inquiries — but with some differences specific to the Report Writer.
Finding the Right Tables
Before adding tables to your schema, you need to know which ones contain the data you're after. The inspect tool — Control + Alt + Click on any field on an Acumatica screen — shows you the underlying Data Access Class (DAC) and field name. This is the most reliable way to identify exactly which table and field to use.
The DAC viewer (accessible with the Customiser role) gives you a full view of a table's structure — field names, types, primary keys, and relationships to other tables. When you're not sure which field to join on, this is where to look.
Adding Tables and Defining Joins
Add your primary table first, then use the 'Add Related Table' option to bring in additional tables. Define the join relationship by specifying which fields link the tables together.
Join types work the same way as in Generic Inquiries:
- Inner join — returns only records that exist in both tables. Use when you expect the related record to always be present.
- Left join — returns all records from the primary table, even if there's no matching record in the joined table. Use when the related record is optional.
- Avoid cross joins — they multiply every row in one table by every row in another, producing an unusable result set.
One capability unique to the Report Writer is table aliasing. If you need to join to the same table multiple times — for example, pulling both a billing address and a shipping address from the same address table — you add the table once and define separate aliased relationships for each use. This keeps the schema clean without duplicating table entries.
Tip: When you're not certain which field to join on, start with a Generic Inquiry for the same data — the join relationships already defined there will tell you exactly which fields to use. Trial and error is normal; the Report Designer makes it quick to save to server and retest.
Refreshing the Schema After Upgrades or Customisations
If custom fields have been added to your system, or if the report is running on an older schema version post-upgrade, use 'Refresh All' and 'Refactor' in the Schema Builder to pull in any new fields. This is particularly important for reports that have been in use for a long time without being touched.
Parameters and Runtime Filtering
Defining Parameters
Parameters are defined in the Schema Builder and appear as selectable options when a user runs the report. Common examples include date ranges, customer IDs, order types, and site locations.
Each parameter has a data type, a prompt label (what the user sees), and optionally a default value. The View Name field links the parameter to a list of valid values from the system — for example, presenting a dropdown of valid order types rather than a free-text field.
Cascading parameters are used when the valid values for one parameter depend on the selection in another — for example, filtering the list of reference numbers based on which document type the user has already selected.
Useful defaulting options include:
- @Today — defaults to the current business date.
- @MonthStart — defaults to the first day of the current period.
- Schema field references — pull a default value directly from a system table, such as the current company or branch.
Applying Parameters as Filters
Defining a parameter is only the first step — you then need to wire it up as a filter condition so it actually affects which records are returned. Filters are also defined in the Schema Builder.
For optional parameters (where running the report without a value should return all records), you need an OR condition alongside the parameter condition: one branch filters by the parameter value when it's provided, and another branch matches when the parameter is empty. Both branches need to be correctly bracketed alongside any AND conditions that also apply.
Date filters typically use greater than or equal to for the start date and less than or equal to for the end date. Both need to be defined as separate filter conditions.
Calculated Fields and Expressions
The Report Writer's expression editor gives you substantial flexibility in how data is displayed and calculated. Some of the most commonly used capabilities:
String Manipulation
- Concatenation — combine multiple fields into a single display using the + operator between strings and field references.
- TRIM / LTRIM / RTRIM — strip leading or trailing spaces from field values, particularly useful before concatenation.
- UCASE / LCASE — force uppercase or lowercase. Note that string comparisons in expressions are case-sensitive.
- LEFT / RIGHT — extract a fixed number of characters from the start or end of a string.
- SUBSTRING — extract a portion of a string starting at a specified position.
- REPLACE — substitute characters or substrings within a field value.
- INSTR — find the position of a character within a string, useful for splitting strings at a known delimiter.
Conditional Logic
Conditional expressions are used extensively throughout the Report Writer — controlling visibility, display values, and calculated results. The basic structure is an IIF (inline if) statement: a condition, a value if true, and a value if false.
A common use case is displaying negative numbers in red. Because the Report Writer doesn't support conditional font colour directly, the standard approach is to place two text boxes on top of each other — one formatted in red, visible only when the value is negative; one in normal colour, visible only when the value is positive or zero.
Aggregation and Running Totals
Aggregation functions — SUM, AVG, MAX, MIN — are applied to fields placed within group footer or group header sections. The aggregation is scoped to the group in which the field appears.
Running totals are handled via report variables, which are defined outside the schema. Variables accumulate a value as each record is laid down on the report. A common example is a customer statement: the opening balance is assigned to a variable at the group header level, each line adds or subtracts from a running balance variable in the detail section, and the closing balance variable is printed in the group footer. This is more complex to set up than standard aggregation, but it's the correct approach for anything that needs to carry a value forward across records.
Grouping, Sorting, and Section Control
Grouping is defined in the Schema Builder and determines how records are organised and subtotalled on the report. Every report should have at least one grouping — even if you're only ever running it for a single record — because groupings are what enable subtotals, group headers, and group footers.
Groups are named in the Schema Builder, and that name corresponds to the header and footer sections visible in the report canvas. Multiple groups can be stacked — for example, grouping first by currency, then by order type, then by order number — and each level gets its own header and footer sections.
Sorting for detail lines is defined within the group definition. Groups themselves are ordered by their definition sequence in the Schema Builder. Sorting can be ascending or descending, and you can sort on fields that aren't necessarily visible on the report.
Key section control options:
- Suppress — hides a section without removing it. Useful for conditionally hiding group footers or header rows.
- Print on every page — keeps a group header visible at the top of each page, useful for column headings on multi-page reports.
- Page break after — forces a new page after each group, useful when each group represents a separate document (e.g., one page per customer statement).
- Reset page numbers — restarts page numbering at the start of each group.
Formatting, Logos, and Sub-Reports
Alignment and Layout
The Report Designer includes alignment tools in the toolbar for selecting multiple fields and aligning them — left, right, centre, or matching width. Hold Shift and click multiple fields to select them, then use the first-clicked field as the alignment reference. This is the fastest way to keep column layouts consistent across sections.
Logos and Images
Images are added using a Picture Box element. For logos, two approaches are available:
- Database-linked logo — references the logo uploaded against the company or branch record in Acumatica. The value string for this can be copied from any existing standard report or form. This is the most common approach and means logo changes in the company record flow through to all reports automatically.
- Embedded logo — an image uploaded directly into the report file. Useful for specific-purpose reports that need a logo not tied to the company record.
In both cases, size the image to its intended print dimensions before adding it to the report. Scaling inside the designer stretches the image proportionally, but logos with text can look poor if scaled significantly. The designer will warn you if the image dimensions don't match the field size.
Sub-Reports
Sub-reports are separate report files embedded within a section of a parent report. They're used when a section of the output needs its own data query — for example, a production order ticket that has a main report for the order header and a sub-report for the operation steps.
The link between the parent and sub-report is maintained through shared parameters. The parent report passes key values (such as order type and order number) to the sub-report, which uses them to filter its own data query. Both the parent and sub-report need matching parameter definitions for this to work.
Managing Report Versions and the Site Map
Understanding version control and the Acumatica site map is important for anyone making changes to production reports.
Version Control
Each time you save a report to the server, you have the option to create a new version with a description of the change. Acumatica retains all versions and allows you to reactivate any previous version from within the report screen. This is your safety net — always create a named version when making significant changes, so you have a clear rollback point.
For minor iterative changes during development, you can save to server without creating a new version, which overwrites the most recent version. Switch to versioned saves once the change is ready for production.
The Site Map
When you create an entirely new report (via Save As with a new file name), the report exists on the server but won't appear in any Acumatica menu until it's added to the site map.
The site map controls all navigation menus in Acumatica. To add a new report, find the site map entry for an existing similar report, duplicate it, and update the screen ID and display name to match your new report. As a naming convention, Avanza-created reports use an 'MAV' prefix on the screen ID to distinguish them from standard MYOB reports.
Once the site map entry is created, an administrator also needs to grant access to the new screen via Access Rights by Screen. New screens are revoked by default — users won't see the report in the menu until access is explicitly granted.
What's Next for Report Writing — AI and the Report Writer
Simon finished the session with a genuinely interesting look at where things are heading, and it's worth covering here because it changes how you might think about the Report Writer going forward.
Acumatica Report Writer files are saved as RPX files — structured XML that is well within the capability of current AI models to read and modify. Simon demonstrated uploading an RPX file directly into Claude, prompting it to simplify a complex customer statement by removing unnecessary groupings, and downloading the revised RPX file ready to open in the Report Designer. The result was accurate enough to use as a starting point, with only minor refinement needed.
He also demonstrated a more operationally significant capability: using the Avanza MCP Connector for MYOB Acumatica to have Claude pull a live customer statement directly from the system and present it as a formatted PDF — without opening Acumatica at all. The output closely matched what the standard Acumatica report produces, generated purely from a natural language prompt.
Neither of these replaces the Report Writer or the skills needed to use it well. But they do suggest that the barrier to creating and modifying reports is going to lower meaningfully over the next few years — and that understanding the underlying structure of RPX files and the Report Writer's logic will remain valuable even as AI tools become more capable of assisting with the build.
Note: The Avanza MCP Connector for MYOB Acumatica — which Simon referenced in this session — connects Claude directly to your Acumatica instance, allowing you to query live data using natural language. It has just completed its early adopter programme and is now available to all Avanza customers.
Watch the full webinar recording
Simon's live demos go considerably deeper than a blog can — particularly the schema builder walkthrough, the expression editor, and the AI demonstrations. Watch the recording here: How to Use the MYOB Acumatica Report Writer (Parameters, Joins, Expressions & More)
Want help with your Acumatica reports?
Our consultants build and modify Report Writer reports for Avanza customers regularly — from minor field additions and layout adjustments through to entirely new custom reports and forms. If there's a report you've been wanting but haven't been able to create, or an existing form that needs updating, get in touch.
Contact us: sales@avanzasolutions.co.nz
About the Avanza Webinar Series
This blog is based on Session 2 of the Avanza Solutions customer webinar series — short, practical sessions led by our consultants, designed to help you get more from MYOB Acumatica. Session 1 covered Generic Inquiries and is available on our website. Session 3 will cover the Modern UI — watch for the invitation.
Presented by Simon Angland, Consultant at Avanza Solutions. Hosted by Nicola Ashburner, Client Relationship Manager.
