Where ERP Complexity Should Live

This article is in reference to:
The Combinatorial Trap in Linear ERP Interfaces
As seen on: cfcx.work

The quiet cost of “just split the line”

There is a moment, buried in everyday finance work, that tells a bigger story than it seems. Someone is entering an invoice, the tax does not calculate correctly, and a colleague says: “just split the line so the taxes work.” The task gets done; the system appears to function. But something important has just happened: the software has pushed its own complexity back onto a human.

This is the “why” behind the original post. It is not really about NetSuite screens or tax groups. It is about who pays for complexity, and in what form. When systems look simple on the surface by offloading combinatorial logic to their users, the organization pays in hidden ways: slower work, more errors, and a quiet erosion of trust in both tools and process.

Seen from that angle, the article makes a practical claim: if leaders do not decide deliberately where complexity should live, it defaults to the most expensive place possible—inside the heads of the people doing the work, repeated thousands of times a month.

From transactions to intent

The post starts from a first-principles claim: a transaction line is not a rule; it is an intent. “Pay this vendor for this service in this context.” The system’s purpose is to take that intent and unfold it into the right accounting, tax, and reporting consequences.

When an ERP provides only a single field for “the code,” it encodes a narrow assumption: one line, one behavior. Reality does not respect that constraint. A single service payment can drive VAT, withholding, surcharges, accruals, and revenue recognition—simultaneously. The gap between that multi-dimensional reality and the linear input model is where the combinatorial trap appears.

The post pushes back against a common design instinct: mirror regulatory outputs directly in the interface. If there are two taxes, add two selectors; if there are five behaviors, ask for five decisions. It argues for a different orientation: map the interface to operational intent and let the system decompose that intent into outcomes behind the scenes.

This is why the author insists that “complexity is conserved.” The hard part does not go away; it only moves. Either architects deal with combinatorics once, in configuration, or operators re-enact it thousands of times, in daily work. The conversation shifts from “how many fields can we add?” to “who should actually carry the complexity—and how often?”

The combinatorial trap as pattern

What looks like a niche tax configuration issue is actually a broader organizational pattern: the tendency to protect design time at the expense of execution time.

On paper, building fifteen tax groups (for five VAT rates times three withholding rates) looks excessive. It bloats configuration objects, complicates testing, and can feel like over-engineering. The seductive alternative is to keep configuration “lean” and teach users a workaround: split lines, override taxes, calculate withholding in Excel.

The post exposes the real trade: one-time architectural work versus perpetual operational friction. Design teams are measured on implementation timelines and object counts. Clerks and accountants are measured on throughput. The combinatorial trap appears when those time horizons and incentives misalign.

The proposed answer—pre-bundled logic—is less about tax groups and more about reclaiming the proper boundary between human judgment and system responsibility. Humans should decide whether to pay, who to pay, and in what context. The system should take that contextual intent and deterministically apply the right patterns: tax combinations, posting, approvals, revenue rules.

In that sense, the piece is also a critique of shallow simplicity. A single field looks simple but forces users into complex mental gymnastics. A well-designed bundle looks complex in configuration but makes the act of using the system feel simple and predictable. The “trap” is accepting UI minimalism as a proxy for true simplicity.

Workarounds as system signals

One of the more revealing moves in the post is the suggested listening test: pay attention to phrases like “split the line so the taxes work” or “we calculate the withholding in Excel.” These are framed not as training failures but as architecture signals.

In many organizations, recurring workarounds are treated as a user problem: more documentation, better onboarding, stricter SOPs. The post suggests flipping that lens. When workarounds cluster around the same transaction types or screens, the system is telling you where it has refused to handle real-world combinatorics.

This reclassification—from user error to design feedback loop—is the deeper “why” behind the article. It invites architects, finance leaders, and implementation teams to treat operational pain as evidence that the system boundary is misplaced. Operators are doing work the system should be doing for them.

The post also points to a second-order effect: once workarounds become entrenched, they harden into culture. New hires learn “how we really do it” from colleagues, not from the system. At that point, even if the architecture improves later, unwinding the habits is its own change-management project. The cheapest time to fix combinatorics is before those habits congeal.

Beyond tax: multi-dimensional reality

By extending the pattern to pricing, approvals, and GL mapping, the post signals that tax is just one visible instance of a general problem: multi-dimensional reality forced through a linear interface.

Pricing that depends on tier, region, and volume is structurally the same as a tax that depends on jurisdiction, vendor type, and service category. Approval routes that depend on amount, department, and cost center are structurally the same again. In each case, the temptation is to expose each dimension directly to the user and let them mentally solve for the intersection.

The author’s alternative is consistent: build composite structures at the system level—pricing matrices, approval groups, account mapping rules—so that one contextual trigger can produce many coordinated outputs. The end user selects a customer and item; the system resolves the combination. The user submits a requisition; the system derives the approval path.

Seen together, these examples describe system design maturity. Mature systems rarely ask users to reconstruct cross-dimensional logic on the fly. They codify stable rules as configuration, treat volatile details as data inputs rather than new rules, and hide combinatorics behind controlled catalogs and defaults.

From insight to practice

Beneath the configuration details, the article is making a cultural proposal. It asks leaders to stop treating operator ingenuity as a free resource and to notice where that ingenuity is being spent propping up brittle systems.

The immediate takeaway is simple: listen for workarounds and treat them as design briefs. Each “we always have to…” is a pointer to an unmodeled combination that could, in principle, be encoded once and reused everywhere.

There is also a governance move. Success for implementation teams can include operator cognitive load and workaround volume as explicit metrics alongside timelines and defect counts. When those measures are visible, the temptation to push combinatorics onto users becomes harder to justify.

The deeper shift is mindset. Treat human attention as a budgeted resource, not an infinite buffer for design shortcuts. If complexity is conserved, then deciding where it lives becomes one of the most leverageful design choices leaders can make.

Viewed this way, the combinatorial trap is not just a tax configuration problem. It is a standing invitation to re-center systems around the people who use them—so that the next time someone says “just split the line,” it marks the beginning of a redesign conversation, not the end of it.