Skip to main content
It’s Unconventional

Methodology

20+ years building, integrating, and fixing enterprise incentive systems 

The pattern

The same problems recur across implementations, regardless of vendor.

▸ Configuration complexity exceeds the programs the configuration is meant to support.

Six-week engagements for changes that should be Tuesday-afternoon decisions.

▸ Calculation lineage is structurally opaque.

When an accrual is wrong, tracing the dispatch path back to the program rule and source transaction requires consulting time that should not be needed.

▸ Multi-program agreements get fractured into multiple system artifacts.

The operationally common case — Volume + SPIF on one negotiation — splits across surfaces. Aggregate reporting becomes manual aggregation.

▸ Settlement timing drifts from program design.

Period-end batch reconciliation produces variance that operators flag as exceptions rather than living state.

▸ Disputes consume more time than the programs save.

Investigation requires data sources the platform doesn't surface.

These aren't bugs in any particular vendor's software. They are consequences of architectural commitments made years ago, when the requirements were different.

The methodology

When I engage on a diagnostic, the work follows a predictable shape.

Wk 1–2

Map current state.

All active programs, their commercial intent, their system encoding, the gap between the two.

Wk 3–4

Identify the load-bearing failures.

Which problems compound. Which are cosmetic. Which are architectural.

Wk 5–6

Architect the alternatives.

Stay-in-place fixes vs. modular replacements vs. full platform transition. Honest trade-offs, with numbers.

Wk 7+

Deliver.

Sometimes hands-on configuration work in the current system. Sometimes guidance during a vendor evaluation. Sometimes early-access conversations about a platform built specifically against these failure modes.

The engagement length and shape adapts. The methodology is stable.

Common questions

Before you book a call.

How long does a diagnostic typically take?

The shape above is roughly six weeks from kickoff to architectural recommendations, with delivery starting in week seven. Real engagement length is set by your program complexity and the depth of system access — some diagnostics run four weeks, some run ten. The pacing adapts; the methodology doesn't.

How is this different from a Vistex or Model N implementation partner?

Implementation partners are paid to make the platform you already chose work. They're structurally incentivized to find configuration paths through the existing software, not to surface architectural alternatives. Advisory work here is platform-neutral: the diagnostic produces honest stay-in-place vs modular replacement vs full transition trade-offs with numbers, regardless of which way the math points.

Do you do hands-on configuration work or only advisory?

Both, scoped to the engagement. Most diagnostics close with hands-on weeks: tightening condition records, fixing calculation lineage, building reconciliation reporting the platform can't surface on its own. When the architecture points toward a vendor evaluation or a platform transition, the hands-on work shifts to guidance during selection rather than implementation delivery.

What platforms is the practice deepest on?

Vistex (all flavors), SAP S/4HANA Settlement Management, the legacy SAP SD Rebate stack (VBOF, MEB1, the condition technique broadly), Model N Channel Data Management, and custom builds layered over any of the above. Cross-border GL determination, multi-tier channel hierarchies, hybrid SPIF + volume rebate programs, and stair-step retroactive structures are common engagement shapes.

Today

Current work.

Most of my time today is split between:

▸ Advisory engagements

with enterprise companies navigating Vistex configuration debt or SAP S/4 migration impact on rebate programs.

▸ Development of next-generation incentive infrastructure

— an AI Rebate Operating System — with select enterprise design partners. See aurgus.com.