Beyond conditional row/column formatting, there is a smaller but genuinely useful layer of GI styling that controls how the results grid itself presents — column widths, number and date formats, grouping bands, and grid-level display options. Getting these right is what separates a GI that reads like a considered report from one that reads like a raw table dump, and it costs almost nothing once you know where the settings live.
Column-level formatting on the Results Grid tab
Each result column carries its own display properties independent of the underlying DAC field's own formatting — a currency field pulled into a GI does not automatically render with two decimal places and a thousands separator unless the GI column is configured to, though in practice Acumatica infers reasonable formatting from the field's data type (PXDBCurrency, PXDBDate) most of the time. Where it does not infer correctly, or where you want a business-specific format, set it explicitly per column:
Column: ARInvoice.CuryDocBal
Display Name: Balance Due
Format: Currency, 2 decimals
Width: 110px
Column: ARInvoice.DueDate
Format: Short Date (dd MMM yyyy)
Alignment: CenterDisplay Name matters more than it seems — it is what a non-technical user sees, and leaving it as the raw field name (CuryDocBal instead of "Balance Due") is a small tell that a GI was built quickly and not reviewed. I treat renaming every visible column as a mandatory last step before handing a GI to a client, not an optional polish pass.
Grouping bands versus flat grids
For GIs where the natural read is grouped — invoices grouped by customer, transactions grouped by account — the results grid supports grouping bands with subtotal rows, configured from the grouping settings on the Results Grid tab tied to a sort/group field. This is distinct from the aggregation-only GROUP BY pattern (covered elsewhere): grouping bands still show every detail row, just visually clustered with subtotals, whereas true aggregation collapses detail rows into one summary row per group. Pick based on whether the user needs to see the individual rows or just the totals — showing both by default, out of indecision, tends to overwhelm rather than help.
Reusable templates for a consistent look across many GIs
Where a client has a house style — a particular currency format, a particular date format, consistent zebra-striping — defining these per GI, per column, every time is exactly the kind of repetitive setup that drifts as more GIs get built by more people over time. Where the build supports referencing a shared style template rather than per-GI settings, use it; where it does not, I keep a short written style guide (date format, currency decimals, standard column widths for common field types) that every GI in a project follows, and I review new GIs against it before they ship. It is a low-tech substitute for a feature the platform does not fully provide, but it is the difference between a client's twenty GIs looking like one coherent reporting suite versus twenty separate one-off efforts.
A single oddly-formatted GI is a minor annoyance. Twenty GIs feeding one client's dashboards and portal, each formatted slightly differently by whoever built it that week, reads as an unpolished product regardless of how correct the underlying data is. Styling consistency is cheap per-GI and expensive to retrofit — apply the house style from the first GI in a project, not the last.
Wrapping up
GI styling beyond conditional formatting covers per-column display names, formats, and widths, plus grouping bands for a clustered-with-subtotals read distinct from true aggregation. None of it is expensive to get right, and because it directly shapes how non-technical users perceive a report's quality, it is worth treating as a required step rather than optional polish — especially once you are building more than a handful of GIs for the same client.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.