Schedule A repackaging at renewal carries three principal patterns: silent dilution, structural simplification and metric switching. Each one looks like routine paperwork. Each one materially changes the cumulative entitlement five years out. The Admodum read on what to watch.
Schedule A repackaging is the act of rewriting the cumulative ordering document at renewal. The historical Schedule A is restructured: lines are added, removed, merged, or reshaped. The repackaging is presented as routine renewal paperwork, but the cumulative entitlement implication is material and persistent.
The repackaging is legal and contractual. The new Schedule A supersedes the older lines in the consolidated portion; the older Schedule As remain in the contract record but, depending on how the repackaging is drafted, may or may not continue to provide an independent entitlement basis.
The wider editorial sits in the Oracle pillar; the foundational Schedule A read sits at Schedule A, anatomised; the renewal-cycle context sits at the Oracle renewal cycle.
Silent dilution is the renewal-time pattern where quantities on existing lines are reduced and options are added on different lines, with the bottom-line total dollar held constant. The headline is unchanged; the underlying entitlement narrows.
The pattern works because the audit-quality read is line-by-line, not bottom-line. A reduction from 100 Database EE Processor licences to 80 Database EE Processor licences (offset by the addition of 4 Multitenant option Processor licences) holds the dollar value but creates a 20-Processor shortfall against any deployment that had been authorised by the 100-Processor entitlement.
The buyer-side discipline is to read each renewal Schedule A line against the prior cumulative entitlement on the same line, and to surface any quantity reduction even when the bottom-line dollar is held.
Structural simplification is the renewal-time pattern where multiple historical Schedule As are collapsed into a single renewal Schedule A. The historical lines are summed (or merged) into consolidated lines; the resulting single Schedule A is presented as the entitlement basis going forward.
The simplification typically loses two things. First, the historical lines that were specific (a Database EE entitlement deployed against a particular cost centre, a particular legal entity, a particular geographic territory) lose their specificity when consolidated. Second, the historical lines that contained negotiated concessions (a higher discount on a particular product, a custom metric definition on a particular line) lose the concession when the line is rewritten as a standard line in the renewal Schedule A.
The buyer-side discipline is to retain every historical Schedule A as a contractual artefact (it does not disappear from the contract record), to read the renewal Schedule A against the historical set, and to surface any specific terms or concessions that the renewal does not carry forward.
Metric switching is the renewal-time pattern where a line moves from one metric to another: Named User Plus to Processor, or Processor to Named User Plus, or either to one of the alternative metrics (Application User, Application User Limited, Custom Suite Universal).
The switch can read favourably to the buyer (NUP to Processor, where the underlying deployment is broad and the NUP minimum has been reached) or unfavourably (Processor to NUP, where the named-user count is harder to enumerate than the processor count). The arithmetic against the processor metric versus the Named User Plus metric reads against the actual deployment, not against the assumed deployment.
The audit-quality read changes against the new metric. A switch from Processor to NUP creates a new compliance read (against named users); a switch from NUP to Processor creates a new compliance read (against deployed cores). The buyer-side discipline is to model the audit posture against the new metric before signing the switch.
The renewal-time discipline against all three patterns is the same. The buyer holds the cumulative Schedule A map (every historical order, every historical Schedule A) as a contractual artefact. The renewal Schedule A is read line-by-line against the cumulative map: every quantity change is surfaced, every option addition is surfaced, every structural consolidation is documented, every metric switch is modelled.
The wider renewal-cadence read sits at the Oracle renewal cycle; the quarter-end timing context sits at the Oracle quarter-end; the BATNA position read sits at the Oracle BATNA.
The renewal-time decision is whether to accept the proposed repackaging, to negotiate a modified repackaging, or to reject the repackaging and renew the prior Schedule As on their existing terms. Each option carries a different cumulative-entitlement implication five years out.
The buyer-side artefacts to hold against repackaging are: the cumulative Schedule A map (every historical order, indexed by date), the entitlement-vs-deployment reconciliation per line (against the audit-quality inventory), the renewal-time draft of any proposed repackaging (compared line-by-line against the cumulative map), and the deployment forecast against which the repackaging is being modelled.
The renewal-time conversation with the publisher is then a negotiation against artefacts, not against the publisher’s preferred narrative of simplification. The publisher proposes a repackaged Schedule A; the buyer reads it against the cumulative map; specific changes are surfaced, negotiated, accepted or rejected on their own terms.
The wider engagement sits in the Oracle practice; the aggregated reading list sits in the Oracle knowledge hub; active renewal moments route to the Renewal Programme; active audit moments route to Audit Defence.
The credible alternative that lets the buyer reject a repackaging proposal.
A senior Admodum Oracle advisor will read your proposed renewal Schedule A line-by-line against the cumulative map on a private call. Active renewal moments route to the Renewal Programme.