Two commission statements for the same sale, and a gap of roughly a thousand dollars. Nobody entered anything twice. Nobody typed a wrong number.

What happened is older and more common than any calculation error: the rule that decides commission lives in more than one place, and the places disagree.

The rule that lives in five places

Distributors rarely have one commission rule. They have a written policy, a spreadsheet the controller maintains, a customization someone built years ago, a report that recalculates independently, and a verbal exception for two long-standing accounts.

Each of those is a legitimate artifact of running a business. Together they form a system with no owner, and the symptom arrives at month end as a reconciliation meeting.

The same pattern appears in pricing overrides, seasonal reorder thresholds, credit holds and customer-specific freight terms. The rule is not the hard part. Agreeing where the rule should live — and who may change it — is.

What Epicor documented in the 2026.1 release

Epicor's release post for Prophet 21 2026.1 describes a generally available release with a clear emphasis on where extension work happens, and it is specific about the capabilities involved.

The stated focus is the continued evolution of Prism. The post names “natural language business rule creation, expanded workflow automation, enhanced security-driven navigation, and deeper access to user-defined data,” framed as making it easier for users to automate processes without heavy technical involvement.

The same post lists operational additions: improved reporting visibility, scheduled task monitoring, mass data management, vendor EFT audit tracking and advanced commission management.

It also names a redesigned WMS interface optimized for touch devices, new Bulk Data API capabilities, Quick Ship and ECM workflow integrations, strategic pricing export automation, and expanded alerts and notifications.

And it describes a backend migration to .NET 10 — in Epicor's words, “delivering improved scalability, performance, and responsiveness across the platform.”

All of that is vendor-stated. It describes what Epicor says shipped, not what any distributor achieved with it.

Four places a rule can live

Surface one: in-product configuration. Natural language rule creation and workflow automation sit inside the application. The advantage is that the rule is expressed in the product's own terms, which generally means it moves with the product rather than against it. The cost is that you inherit the configuration layer's expressiveness — if the rule needs something it does not model, you have found the edge.

Surface two: the API surface. The documented Bulk Data API additions and the existing integration endpoints are the right home for a rule that spans systems — the order in the ERP, the record in a warehouse system, the entry in finance.

Surface three: custom code and direct data access. SQL and custom logic remain available, and sometimes they are the only honest answer. They are also the surface with the largest blast radius when the platform's internals move.

Surface four: outside the product entirely. When a rule spans several systems and none of them owns it, the answer is usually a facade that translates between them. Microsoft's anti-corruption layer pattern describes exactly this: a layer that translates requests between subsystems that do not share semantics, so a dependency on an outside system does not limit the design of the one you control.

Why this choice outlives the person who made it

A customization is a promise that someone will still understand it in three years. That promise is usually broken quietly, when the developer leaves and the code keeps working exactly as written.

A backend migration makes the tension explicit. When a platform moves its internals — as a .NET 10 migration does — logic written against the previous foundation becomes work to re-verify. Logic expressed through configuration or a documented interface is a different kind of risk.

That is inference about relative exposure, not an Epicor commitment. Nothing in the release post promises that configured rules are upgrade-proof, and nothing states that customizations will break.

What is defensible is narrower and still useful: the further a rule sits from the platform's internals, the less an internal change can reach it, and the easier it is to explain to an auditor who has never opened a code editor.

Where a workflow has to be replaced piece by piece rather than all at once, Microsoft's strangler fig pattern gives the shape: route specific functionality to the new implementation while the old path keeps running, and decommission the old one when the new one has earned trust.

The two documented features that move money

Two items on Epicor's own list deserve a second look, because neither is a convenience feature.

Advanced commission management determines what a salesperson is paid. Vendor EFT audit tracking records how money left the business. Both are financial controls wearing the label of product enhancements.

That makes two questions worth asking before either is configured: who is permitted to change the rule, and what record survives when they do? A commission rule that can be edited by anyone with screen access is a payroll control gap, not a settings preference.

Neither question is answered by a capability list. Both are answered by a decision someone has to make deliberately.

Six decision criteria

  • Rule ownership. For each business rule, is the surface it lives on named, and is the person who may change it named?
  • Upgrade exposure. Would a backend migration turn this rule into a project, or leave it untouched?
  • Expressiveness fit. Does the rule fit the chosen surface without contortion, or are you encoding a workaround in a system not built for it?
  • Authority trail. When this rule acts — approves, holds, releases, pays — does it leave a record of who authorized the action?
  • Evidence for suppliers. Can you show a purchaser what the rule does and who controls it, in language they can check?
  • Exit path. If this automation has to be switched off, how long does that take and who decides?

The fifth criterion has a reference point. NIST's Secure Software Development Framework exists partly because buyers needed a common vocabulary to use with suppliers during acquisition. It is guidance, not a certification, and it says nothing about ERP configuration — but the instinct is right: a rule nobody outside the build team can describe is a rule nobody can procure against.

Three delivery options

Consolidate into configuration. Move as many rules as the in-product layer can express, and document the ones that do not fit. Cheapest to sustain, and the fastest to hit a ceiling.

Push cross-system rules through an interface. Appropriate when the rule genuinely spans applications. It moves the rule out of a developer's repository and into something an operations lead can read.

Keep custom code for the rules that are actually yours. Some logic reflects how your business operates and will never be a product feature. The discipline is to isolate it: a defined boundary, a documented contract, tests that fail on the old behavior, and a named owner.

Most distributors need all three, applied deliberately rather than by whoever was available that quarter.

A 30-day pilot

  • Days 1 to 5. Pick one disputed rule — commission on a split sale, a customer-specific price override, a seasonal reorder threshold.
  • Days 6 to 12. Write down every place the rule currently exists, including the spreadsheet. Expect five. The list is the deliverable.
  • Days 13 to 20. Decide the intended surface, and record why the other options were rejected.
  • Days 21 to 30. Implement on the chosen surface for a single test case, then have someone who did not build it reconcile the output against the policy.

Four indicators worth baselining

Rule duplication count: how many places one business rule is implemented. Reconciliation hours per close: time spent explaining differences between systems. Change lead time: elapsed time from an approved policy change to the rule working correctly. Credential exceptions: integration accounts whose rights exceed the task, counted as a number you intend to drive to zero.

Baseline all four on one rule before the pilot. A vendor's capability list describes what the software can do; these four describe whether your rules are under control.

What is vendor-stated, and what is not

The 2026.1 capability list, the Prism description, the commission and EFT audit features, and the .NET 10 migration come from Epicor's release post on its own blog. They are vendor statements about a product release, and the performance language is Epicor's, not an independent measurement.

Nothing here establishes that any distributor reduced reconciliation effort, shortened a close, or improved a commission dispute outcome. No customer result, savings figure or performance benchmark is asserted, and the opening scenario is illustrative rather than a client story.

What remains unknown

  • Whether configured Prism rules and workflow automations survive future upgrades without rework. Epicor does not make that promise in the material reviewed.
  • How much of a typical distributor's custom logic the in-product configuration layer can actually express.
  • Whether the .NET 10 migration has required customization rewrites at customer sites, and how many.
  • Any measured effect of natural language rule creation on error rates.
  • Whether the audit trail behind vendor EFT tracking is configurable, and how far back it retains.
  • Market data. None was reviewed for this edition, so no stock movements are reported.

Evidence notes and limits

The 2026.1 capabilities, the quoted phrasing on Prism and on the .NET 10 migration, and the commission and vendor EFT features come from Epicor's release post on its own blog. They are vendor statements about a product release and are labeled as such in the text.

The Microsoft pattern descriptions — anti-corruption layer and strangler fig — are architectural guidance about how to structure systems. They are not measurements, and neither is presented here as evidence that any organization achieved a particular result.

NIST SP 800-218 is cited only for the existence of a framework offering a common vocabulary that purchasers and suppliers can use in acquisition. It is guidance, not a certification, and it makes no claim about ERP configuration or business rules.

The four surfaces, the criteria, the options, the pilot and the indicators are this publication's analysis and suggested method. They have not been validated as a protocol. The advertisement above is separate from this analysis and is not a source for any claim in it.