Maximo Contracts and Warranties: Setting Up LP, PC and Warranty Terms

Contracts are one of the most under-used parts of IBM Maximo. Sites buy the platform for work orders and assets, get those running, and leave the Contracts module as an afterthought. Then a year later someone asks why a supplier billed above the agreed rate, or why a pump was replaced at full cost when it was still under warranty. Both answers live in a module nobody configured. This guide walks through the contract types, how to set up price and warranty terms that actually enforce, and the reports that turn contract data into money saved.

The seven contract types, and where each belongs

Maximo ships several contract types out of the box, and each one exists for a specific commercial situation. Choosing the wrong type is the single most common mistake I see. Here is the plain-language version:

• Purchase contract. A commitment to buy specific items or services from a vendor, usually over a term. Good for negotiated supply where you know roughly what and how much.
• Blanket contract. A ceiling of total spend with a vendor. You draw down against a maximum value using releases (POs) rather than agreeing every line up front. Good for ongoing consumables and services.
• Price contract. A catalogue of agreed unit prices for named items. It does not commit you to a quantity, it locks the price. When a requisition or PO references it, Maximo pulls the contracted price. This is the enforcement contract.
• Lease and rental contract. For assets you lease or rent rather than own, with scheduled payment terms and end-of-term handling.
• Master contract. A parent agreement that groups several associated contracts under one vendor relationship and shared terms.
• Labour rate contract. Agreed hourly rates by craft or skill for a labour vendor, so time booked to a work order costs the negotiated rate.
• Warranty contract. Coverage terms for assets or services, tracked by duration or by meter, so Maximo can warn you before you spend on something still covered.

A price contract, worked end to end

Let me make the price contract concrete, because this is where the payback is. Suppose you have negotiated fixed rates with a filter and belt supplier for the year. You create a price contract, associate the vendor, and add catalogue lines:

• Line 1: item FILT-2400, agreed unit price 42.00, effective 01 Jan to 31 Dec.
• Line 2: item BELT-V8, agreed unit price 18.50, effective 01 Jan to 31 Dec.
• Line 3: item FILT-4800, agreed unit price 61.00, effective 01 Jan to 30 Jun.

Each line carries the item, the unit price, and effective dates. Now the enforcement behaviour: when a storeroom raises a requisition for FILT-2400 against this vendor, Maximo looks up the active price contract line and pulls 42.00 automatically. The requisition references the contract, the PO inherits it, and the buyer does not retype a price or accept whatever the vendor quotes. That reference is the audit trail: you can trace any PO line back to the contract line that priced it.

The effective dates matter more than people expect. Line 3 expires on 30 June. A requisition raised on 01 July for FILT-4800 finds no active line and falls back to the item's standard cost or a manual price, which is exactly the signal you want that a renegotiation is due.

What happens when a price changes mid-term? You do not overwrite the line. You revise the contract. The correct pattern is to end-date the current line and add a new line, or create a contract revision, so the old price still explains historical POs and the new price applies going forward. If you simply edit the number in place, every past PO now appears to reference a price it never actually used, and your spend history stops reconciling. Revision preserves history; editing destroys it.

Warranty contracts against assets and against service

Warranty is the contract type with the fastest visible payback, and the one most sites never switch on. A warranty contract records coverage and lets Maximo warn you before you pay for work that someone else should cover. You can cover the asset itself or the service performed on it. For a related, vendor-neutral view of the discipline, see my note on warranty management in asset systems.

Two ways coverage expires:

• Duration-based. Coverage runs for a fixed period from a start date, for example 24 months from commissioning. This is the common case for most equipment.
• Meter-based. Coverage runs until a meter reading is reached, for example 100,000 km or 10,000 running hours, whichever the terms specify. Maximo watches the asset meter and treats the warranty as expired once the reading passes the limit, even if calendar time remains.

You associate the warranty to a single asset or to an asset group, so a batch of identical pumps commissioned together can share one warranty definition rather than needing a record each. Service warranties work the same way but cover the labour or repair performed rather than the physical asset, which matters when a contractor guarantees their own work for a period.

The terms and conditions library

Maximo keeps a central library of terms and conditions, reusable clauses you attach to contracts and purchase orders rather than retyping. Each term has a type, a description, and flags that control how it behaves downstream. The useful ones flow onto the PO so the vendor sees the same terms Maximo is tracking.

The flow is simple: define a term once in the library, associate it with a contract, and the terms marked to carry forward appear automatically on every PO raised under that contract. It is a genuinely good feature. The honest caution is that most sites populate this library once at go-live, tick a handful of terms, and never review it again. Payment terms drift, penalty clauses change in the real contract but not in Maximo, and the PO ends up printing terms nobody has checked in three years. Put a calendar reminder on it.

Approval, revision and status flow

Every contract moves through a status lifecycle, and understanding it prevents the "why can't I edit this" support calls. A contract is created in draft, typically WAPPR (waiting on approval), where you build lines and terms freely. Once complete it is submitted and approved, moving to APPR (approved), at which point it becomes active and enforceable and the line detail locks.

To change an approved contract you create a revision. Maximo copies the current contract into a new revision number, leaves the original in a revised state for history, and lets you edit the copy through its own approval cycle. When the revision is approved it supersedes the prior version. This is exactly why the mid-term price change earlier goes through revision rather than a raw edit: the lifecycle is designed to keep an auditable chain of what was agreed and when. Contracts can also be suspended when a vendor relationship is paused and closed when the term ends, and each transition can be tied to your organisation's approval routing.

The reports that make contracts useful

A contract module nobody reports on is a filing cabinet. Three reports turn it into an operational tool, and I set these up on every implementation:

• Contracts expiring within 90 days. A rolling list of every contract, price line, and warranty approaching its end date. This is the single most valuable report because it converts silent expiry into a planned renegotiation. Run it monthly and route it to procurement.
• Spend against blanket value. For every blanket contract, committed and released spend versus the agreed ceiling. It tells you which vendors are about to exhaust their blanket (raise the next one before work stops) and which blankets were over-provisioned and can shrink at renewal.
• Warranty claim candidates. Work orders and costs booked against assets that were in warranty at the time of the work. This is the report that pays for the whole module: it surfaces spend you may be able to recover, and over a year the recoveries usually dwarf the configuration effort.

None of these need custom development. They are straightforward queries over the contract, PO, work order, and asset tables, and Maximo's built-in reporting or a KPI tile handles all three. The value is not the SQL, it is the discipline of running them on a schedule.

Closing thought

Maximo Contracts rewards a little up-front rigour. Pick the type that matches the commercial reality, use price contracts where you want enforcement, populate warranty start dates and meters so the alerts actually fire, keep the terms library honest, and revise rather than edit so history holds. Do that and the three reports above start returning real money. If you are still mapping how the module fits the wider platform, my introduction to IBM Maximo sets the context.

Independence note: I am not affiliated with, sponsored by, or reselling for IBM. This is practitioner experience from configuring and running Maximo on live sites. Verify version-specific behaviour and screen names against the official documentation for your release before you build.

References: IBM Maximo Manage documentation · IBM Maximo Application Suite