Acumatica GI Conditional Formatting — A Style Template

A GI results grid that turns overdue balances red without anyone opening Excel is a small thing that reads as polish to a client, and it takes about fifteen minutes once you know where the setting lives — which is not obvious, because it is attached to the DAC field's style attributes, not to the GI itself in most builds, or via a style condition on the results grid depending on version.

Two places conditional formatting can come from

There are genuinely two mechanisms and people conflate them constantly:

• PXUIField style hints on the underlying DAC/graph — if the field already carries conditional styling logic in the screen it comes from (a red balance on the AR Invoice screen, for instance, driven by graph-side RowSelected logic setting PXUIFieldAttribute.SetError or a style attribute), a GI built directly over that BQL field generally does not inherit that styling, because the GI results grid is a different rendering pipeline from the screen grid. This trips people up: "the balance is red on the AR screen but black in my GI" is expected, not a bug.
• GI-level style templates — a small set of formatting rules you define on the GI's Results Grid tab (or via a style template referenced by the GI, depending on build) that evaluate a condition per row/column and apply a CSS-like style. This is the one you actually configure for GI-specific conditional formatting.

Building a conditional style rule

The pattern is a condition plus a style, attached to a specific result column:

Column:      ARInvoice.CuryDocBal
Condition:   ARInvoice.DueDate < [today]  AND  ARInvoice.CuryDocBal > 0
Style:       Error   (maps to the platform's red/warning row style)

Column:      ARInvoice.CuryDocBal
Condition:   ARInvoice.CuryDocBal = 0
Style:       Success (maps to green/muted)

The available style keywords track the platform's existing semantic styles (error, warning, info, disabled-looking) rather than arbitrary hex colors in most builds — which is a feature, not a limitation: it means your "overdue" red matches the red used everywhere else in Acumatica, so it reads as native rather than bolted on.

Reusable style templates versus one-off rules

If you are formatting the same "overdue = red, current = default, paid = muted" logic across a dozen AR-adjacent GIs, defining the condition fresh in each one is how they drift out of sync the first time someone tweaks the overdue threshold in one and forgets the other eleven. Where the build supports it, define the logic once as a shared style template referenced by field name/condition pattern and reuse it; where it does not, I keep a documented "standard conditions" snippet (literally a text file) that gets pasted consistently, and I name conditions descriptively enough that a future maintainer can tell at a glance which GIs share a rule.

Wrapping up

GI conditional formatting is a Results Grid-level feature distinct from whatever styling the source screen already applies — a GI does not automatically inherit a screen's red-balance logic, you redefine it as a style condition on the results column. Use the platform's semantic style names so formatting stays visually consistent with the rest of Acumatica, and remember it is a browser-only convenience that does not travel into exports.