Equipment Rental Contract Management

The problem

Rental is a different transaction shape from sale, and Dynamics 365 Finance & Operations was built around sale. An item you rent does not leave your balance sheet when it ships — it goes out on hire, earns revenue per day or week or month, comes back, gets inspected, gets repaired, and goes out again. Standard order-to-cash has no native concept of an off-rent date, a reservation held against a physical serialised asset for a future window, or a billing run that invoices every open contract for the period just elapsed.

So rental operators improvise. Availability lives in a spreadsheet or a whiteboard, which means double-booking is a matter of when, not if. Contracts are tracked in a separate system that does not know what the ERP thinks is on hand. Period billing is a monthly manual exercise where someone works out which contracts were live for how many days, and the errors go in both directions — unbilled hire days on one side, disputes and credit notes on the other. Damage and loss charges get raised late or not at all. And because the rental fleet is not properly represented in inventory, utilisation — the single number the business runs on — is a reconstruction rather than a report.

What ECOSIRE builds

ECOSIRE builds rental contract management as a native Dynamics 365 Finance & Operations extension. This is a build-to-order engagement: we scope against your fleet, your rate structures and your revenue recognition requirements, then build, deploy and hand over the source. There is no pre-built product to download.

The contract and reservation model

We build rental contract header and line tables as extension objects, with X++ classes for the contract lifecycle — quotation, reservation, on-rent, extension, off-rent, return inspection, close. Contract lines reference released products and, where you rent serialised assets, the specific inventory serial or asset record, so a reservation is a claim on a physical unit rather than on an abstract quantity.

Availability is calculated against reservations, on-rent contracts, transfer orders and maintenance blocks, and rendered as a calendar and a utilisation view. Because it reads inventory dimensions — site, warehouse, location, serial — availability answers the question the counter staff actually ask: can I give this customer this machine, from this depot, on that date. Overlapping reservations are prevented at the service layer, not by convention.

Rates, billing and the ledger

Rate cards are modelled as extension data with daily, weekly, monthly and minimum-hire tiers, customer-specific rates and seasonal overrides. The period billing engine runs as a recurring batch job: it walks open contracts, computes billable duration for the period against the rate tier and any minimum-hire rules, and generates sales orders and invoices through standard F&O posting so that tax, trade agreements where relevant, and financial dimensions all behave normally. Because invoicing goes through the standard path, revenue and receivables land in the ledger with your normal posting profiles, and ledger dimensions carry the depot, fleet category or cost centre you report on.

Proration for mid-period on-rent and off-rent dates is explicit and configurable — this is the single most common source of rental billing disputes, so the rules are made visible rather than buried in code.

Off-rent, inspection, damage and loss

Off-rent is captured as an event with its own timestamp, which stops the billing clock independently of when the asset physically arrives back. Return inspection records condition, fuel or consumable levels, missing accessories and damage, and raises the corresponding charges as additional contract lines that flow into the next billing run. Where an asset is written off or not returned, a loss charge is raised and the inventory disposition handled so the fleet register and the ledger agree. Where you run asset management, returned units can be routed to maintenance and held unavailable until released, so a machine awaiting repair is never offered to the next customer.

Integration surface and operations

Contracts, reservations, availability and rate cards are exposed as data entities over OData so depot systems, a driver or delivery app, or a customer-facing channel can read and write through a supported contract. Bulk loads — an initial fleet import, historical contract migration — run through the data management framework. Approvals for rate overrides, credit exceptions or damage waivers route through the workflow framework so a discount is an approved decision with an audit trail. Where movement is recorded in the yard, the warehouse mobile app flows can be extended for despatch and return scanning. All ERP-side code ships as non-overlayered X++ extension models, packaged as a deployable package and promoted through your own LCS/sandbox pipeline. Where a field or counter-staff experience is needed outside the F&O client, we can build it on the Power Platform against the same entities — that is a scoping decision, not an assumption.

Who this is for

Equipment rental operators already running or committing to Dynamics 365 Finance & Operations: construction plant hire, industrial and specialist equipment, event and temporary infrastructure, and manufacturers moving to an equipment-as-a-service model where the same asset is rented repeatedly rather than sold once. It suits multi-depot and multi-legal-entity operators, since availability and billing both need to respect where an asset physically sits and which entity owns it.

It is not the right fit for short-term consumer rental with no contract, no serialised fleet and no period billing — the machinery here exists to handle the complexity that model does not have.

How delivery works

1. Scoping call. We work through your fleet structure and serialisation, rate card model, minimum-hire and proration rules, damage and loss policy, depot and entity structure, and revenue recognition requirements. 2. Fixed quote. A written scope and a fixed price agreed before any build starts. Subsequent changes are quoted as change requests rather than absorbed. 3. Build. Typically 2–4 weeks depending on scope, built against a copy of your configuration. Rental billing rules are the part most worth getting exactly right on paper first. 4. Install in test. The deployable package is deployed to your sandbox via your LCS pipeline and validated with your team against real contracts — including a parallel billing run against a period you have already invoiced, which is the most direct way to prove the engine. 5. Production. After your sign-off, promoted through your normal release process under your controls. 6. Support. A defined post-go-live support window covering defects in what we built, with full source handed over so you can maintain and extend it yourself.