A distributor's ERP is running. Orders ship, invoices post, the warehouse picks. Then someone opens the commission workbook.

Three days before payroll, finance reconciles it by hand, because the splits on two dozen accounts do not match what the standard calculation produces. Nobody wants to touch the core. So the workbook persists.

That workbook is the most common extension request in distribution, and it is almost never a sign the ERP failed.

What this analysis can and cannot support

Two limits belong at the top, because the temptation in a piece like this is to reach for a customer story.

First, no Epicor product documentation, release note, data sheet or published customer story was available to review for this analysis. So nothing below asserts what Prophet 21 includes in its commissions, pricing or replenishment modules, and no distributor's outcome is described. The question here is narrower: where extension logic should live.

Second, the mechanism illustrated by the workbook is this publication's reading of a common pattern, not a documented case. No employer, deployment or result is identified.

What the structural argument rests on is three retrievable documents: Microsoft's architecture guidance, NIST's Secure Software Development Framework, and NIST's Cybersecurity Framework. They support the architecture and the procurement language. They do not measure your ERP.

Most extension requests are definition problems

Commission disputes are rarely about arithmetic. They are arguments about what a sale is.

Is a split recognized at order entry, at shipment or at payment? Does a credit memo reverse the commission in the same period, or the next? When two reps share an account, is the split a percentage of margin or of revenue? Does a return claw back the original period or reduce the current one?

Each answer is a business rule. Each system in the chain may have been built with a different one, and none of them is wrong until someone writes the definition down.

This publication's reading is that commission logic belongs in one named place, with a written definition of the triggering event, and that a workbook is survivable only while one person understands it. That is a documentation problem before it is a software problem.

Three places an extension can live

Every extension request resolves to one of three locations, and the choice is a budget decision before it is a technical one.

Inside the core. Configuration and delivered functionality. Cheapest to sustain, and the only option that inherits the vendor's upgrade path automatically. The constraint is real: if the requirement genuinely does not fit, forcing it here is how a clean implementation becomes an archaeology project.

At a boundary layer. A translation service between the ERP and everything else, holding what differs between systems. Durable across upgrades, and it is not free.

Beside the core. A separate application or portal that reads from the ERP and owns its own logic. Fastest to ship, and it introduces a second place where the truth lives.

Most distributors end up with all three. The failure mode is not choosing wrong once. It is choosing "beside" by default, repeatedly, until nobody can say which system owns commission calculation.

Seasonal reorder thresholds: the number that was right in March

A static reorder point is a bet that demand is stable. Distribution is seasonal by nature, so the bet is wrong for part of every year, and the cost shows up as either excess inventory or a stockout on a fast mover.

Two levers exist, and they carry different obligations.

Move the threshold. Change the reorder point on a calendar or a demand signal. Simple, auditable, and dependent on someone remembering to change it back in January.

Move the logic. Compute the threshold from a demand model. More responsive, and now a forecast sits between the buyer and the purchase order, which means somebody has to own it on the day the model is wrong.

The second option is where distributors most often underestimate the governance cost and overestimate the accuracy gain. A model that is right most of the time still produces exceptions, and exceptions are the workload.

What a boundary layer costs, honestly

Microsoft's anti-corruption layer pattern describes implementing a facade or adapter layer between different subsystems that do not share the same semantics, translating requests one subsystem makes to the other so that dependencies on outside subsystems do not limit an application's design.

Microsoft is also specific about the costs, and these are the parts an extension proposal usually omits: the layer adds latency to calls between the systems, it adds a service that must be managed and maintained, and it can become a single point of failure. The guidance further advises focusing the layer on translation logic and keeping business rules and orchestration out of it.

Read that last point against the commission example. Deciding what constitutes a sale is a business rule. Deciding how payroll spells it is translation. Put both in the same component and the layer quietly becomes a second ERP with worse documentation.

This is also the honest answer to "can we just integrate it?" Yes, and the integration is a product with an owner, a support rotation and a failure mode. Budget accordingly or choose a different location.

The portal question: who is actually the user

Most distributor portal projects begin with the customer and discover the real transaction volume is internal.

A customer ordering portal and a portal built for the people who take orders and manage inventory are different products with different permission models. One is a storefront. The other is a workstation.

A distributor portal typically has to answer three questions a generic web form cannot: what does this user see across locations, what may they change without approval, and what happens to the request when the ERP is unavailable. The third question is the one that decides whether the portal becomes trusted or quietly bypassed.

Buy the vocabulary before you buy the promise

NIST's Secure Software Development Framework, SP 800-218, published February 2022, recommends a core set of high-level secure software development practices that can be integrated into each SDLC implementation.

Its stated value for a buyer is narrower and more useful than a checklist. Because the framework provides a common vocabulary for secure software development, NIST writes, software purchasers and consumers can also use it to foster communications with suppliers in acquisition processes and other management activities.

That is precisely what an extension procurement packet usually lacks: shared terms for asking who owns the rule, who tests it after an upgrade, and who signs when a calculation silently fails.

NIST is equally direct about the ceiling. The Cybersecurity Framework is described as helping organizations better understand and improve their management of cybersecurity risk. That is guidance, not certification, and nothing in it certifies that a vendor's extension is sound or that your commission logic is correct.

A supplier who offers a framework name instead of a test plan has offered vocabulary, not evidence.

Four questions before you add a field

  • Does the vendor already do this? Ask for the feature name and the documented behavior, not an assurance that it is possible.
  • What breaks after the next upgrade? If the answer is unknown, the change is not ready. Extensions are cheapest to build and most expensive to carry.
  • Who owns the rule? A named role for the commission definition, the reorder threshold and the pricing exception. Ownership by department is how two departments get two answers.
  • Can it be reconstructed from records? Given a completed commission run or a modified order, can someone who did not build the extension explain it without an interview?

A 30-day pilot

  • Days 1 to 5. Pick one extension request with real volume. Commission splits on a subset of accounts, or one seasonal category. Not the whole catalog.
  • Days 6 to 12. Write the definition down: triggering event, rounding, reversal handling, named owner. If two people disagree, that disagreement is the finding.
  • Days 13 to 18. Decide the location — core, boundary or beside — and record why in one paragraph. That rationale is what makes the next request faster.
  • Days 19 to 25. Build it in that location only, with the rule where it belongs and the translation where it belongs.
  • Days 26 to 30. Have someone who did not build it reconstruct three completed calculations from records alone, then run one in a test environment against the next scheduled update.

Four indicators worth baselining

Extension count by location, because a rising "beside" count predicts future work. Time to explain one calculation from records, in minutes. Manual reconciliations per cycle for a request type the system supposedly handles. Upgrade survival rate, meaning how many extensions required rework at the last update.

Baseline all four before the pilot. None requires a vendor benchmark, and all four describe your operation rather than someone else's.

What remains unestablished

  • What Prophet 21 includes in its commissions, pricing or replenishment functionality. No product documentation was available to review.
  • Whether a boundary layer reduces total integration cost at any specific scale. That is a per-estate question.
  • Whether any of these approaches improved fill rates, reduced reconciliation time or returned staff capacity at any organization.
  • How much of a typical extension backlog is entitlement friction versus genuine functional gap.
  • Market data. None was reviewed, so no stock movements are reported.

Evidence notes and limits

Microsoft's anti-corruption layer guidance is cited for the described facade between subsystems that do not share semantics, and for its own stated trade-offs — added latency, an additional service to manage and maintain, and the risk of it becoming a single point of failure — and its advice to focus the layer on translation logic while keeping business rules and orchestration out of it. It is architectural guidance, not a measurement, and no effort, cost or outcome is attributed to implementing one.

NIST SP 800-218, published February 2022, is cited for its described purpose of recommending secure software development practices that can be integrated into an SDLC, and for its statement that a common vocabulary helps purchasers and suppliers communicate in acquisition. The NIST Cybersecurity Framework is cited only as a tool to help organizations understand and manage cybersecurity risk. Neither says anything about distribution software or extension architecture, and neither is a certification.

No Epicor product documentation, release note or published customer story was available to review for this analysis. Accordingly, this article makes no claim about any Epicor product's functionality, no claim about any customer's measured results, and no claim that a specific deployment achieved a specific saving.

The three locations, the four questions, the pilot, the indicators and the reading of the commission workbook are this publication's analysis and suggested method. They have not been validated as a protocol, and nothing here establishes that any organization reduced cost, improved fill rates or recovered staff capacity.

The advertisement above is separate from this analysis and is not a source for any claim in it.