Equipment Rental & Asset Utilization

The problem

NetSuite's order-to-cash flow assumes you sell an item once and it leaves the building. Rental does the opposite: the same physical unit goes out, comes back, gets inspected, gets repaired, and goes out again — and it earns revenue for a period rather than at a moment. Nothing in standard Sales Orders, Item Fulfillments or Invoices models a rental period, a reservation that blocks a unit for a date range, an on-rent/off-rent state per serial number, or a return inspection that decides whether the customer is charged for damage.

So rental businesses running NetSuite end up with a shadow system. Availability lives in a spreadsheet that the sales rep alt-tabs to before promising a delivery date. Rental rates live in a PDF price list. Recurring invoices are typed by hand every month, and the month someone forgets, the revenue is simply gone. Off-rent dates arrive by text message and get keyed in days later, so utilisation reporting — the single number that tells a rental business whether to buy more fleet — is wrong by construction. Damage recharges are argued about because nobody photographed the unit when it went out.

ECOSIRE builds a rental layer inside NetSuite so the rental contract, the physical asset and the general ledger stay one system.

What ECOSIRE builds

Rental contract and rental line records

A custom record for the rental agreement, with a child sublist of rental lines. Each line references a real inventory or serialised item, an out date, a due-back date, an actual return date, a rate basis (hourly, daily, weekly, four-weekly, monthly) and a rate. The contract carries customer, subsidiary, department, class, location and any custom segments you already use, so everything it posts lands in the right dimensions of your chart of accounts.

User Event scripts on the contract enforce the rules that matter: you cannot save a line whose out date is after its due-back date, you cannot release a unit that is already committed elsewhere in that window, and closing a contract requires every line to have a return outcome.

Availability and reservation engine

A reservation model that treats a date range, not a quantity, as the thing being consumed. For serialised fleet, availability is computed per serial number by scanning existing reservations, open contracts and any maintenance holds. For bulk non-serialised items, it is computed as quantity-on-hand at a location minus committed quantity across the overlapping window.

The engine is exposed three ways: as a Suitelet calendar and timeline view your dispatch desk works from, as a field-level check that fires when a rep picks an item and a date range on a contract, and as a RESTlet so an external booking site or a field app can ask "is unit X free from the 4th to the 18th" and get a straight answer.

Recurring rental billing

A Map/Reduce script that runs on a schedule, finds every rental line whose next billing date has arrived, prorates the period against the rate basis, and generates Invoices grouped the way you want them — one per contract, one per customer, or one per customer per project. Proration handles mid-period starts, mid-period returns, non-billable days, and rate steps such as a lower weekly rate once a unit has been out beyond seven days.

Because it is Map/Reduce, a run over a large fleet processes in parallel and yields cleanly, and a failure on one contract does not stop the rest of the billing run. Every generated invoice line carries a reference back to the rental line and the billed period, so a customer query is answerable without archaeology.

Off-rent, return and condition capture

A return process that records the actual off-rent timestamp, stops the billing clock from that instant, and captures a condition assessment against a checklist you define. A failed check can automatically create a damage recharge line, move the unit into a maintenance status that removes it from the availability pool, and attach photographs to the asset record via the File Cabinet.

User Event and Scheduled scripts keep asset status honest: a unit cannot be marked available while an open maintenance record exists against it, and units due back today or overdue appear on a dispatch dashboard rather than being discovered at month end.

Utilisation and fleet reporting

Saved searches and a Suitelet dashboard computing time utilisation (days on rent over days available), financial utilisation (revenue over the asset's replacement value), revenue per unit, downtime by cause, and overdue-return exposure. Reporting is dimensioned by subsidiary, location, item category and custom segment, so a OneWorld group can look at one depot or the whole fleet without a spreadsheet in between.

Integration surface

SuiteTalk REST endpoints and custom RESTlets so a field-service app, a telematics feed or a customer self-service portal can create a booking, post an off-rent, or fetch a live availability window. All external calls are authenticated with token-based authentication under a dedicated integration role whose permissions are scoped to the records this app touches.

Who this is for

Equipment hire businesses — construction plant, access equipment, generators, scaffolding, event and AV kit, medical devices, containers, vehicles — already running NetSuite for financials and inventory, and running rental operations somewhere else. It suits companies with a serialised fleet where the question "where is unit 4471 and when is it free" needs an answer, and companies billing recurring rental where manual invoicing is leaking revenue.

It is equally relevant to sell-and-rent hybrid businesses, where the same item may be sold outright, rented, or rented with a purchase option, and the accounting for each path is different.

Roles and permissions

We define the role model alongside the build: a dispatch role that can reserve and release but not change rates, a rental operations role that can price and amend contracts, a finance role that owns the billing run and credit decisions, and a read-only depot role for the yard. Permissions are set on the custom records and scripts themselves, not left to the default employee role.

How delivery works

1. Scoping call. We walk your rental process end to end — rate structures, proration rules, what "available" means in your business, how returns are inspected, how damage is recharged, what your dispatch team looks at each morning. We look at your existing item setup, locations, subsidiaries and custom segments so the build fits what you already have rather than duplicating it.

2. Fixed quote and specification. You receive a written specification listing every custom record, field, script, saved search and role change, plus the fixed price and the delivery schedule. Nothing starts until you approve it. If scope changes later, we re-quote before building.

3. Build. ECOSIRE develops the app as an SDF project using SuiteScript 2.1 — User Event, Map/Reduce, Scheduled, Suitelet and RESTlet script types, SuiteFlow where a state machine is the right tool, and custom records for the rental data model. Typical build time is one working week depending on the proration and pricing complexity agreed at scoping.

4. Install into your sandbox. We deploy to your sandbox or a development account first and configure it against your real chart of accounts, item records and subsidiaries. You test with your own data and your own people, and we work through the change list with you.

5. Promote to production. After you sign off in sandbox, we deploy the same SDF project to production, migrate configuration, run a controlled first billing cycle with you watching, and hand over the source. It is an unmanaged bundle or SDF project in your account — you own the code and can read every line of it.

6. Support window. A defect-fix and question-answering window follows go-live, agreed at quote time. Extended support and enhancement work is quoted separately.

What this is not

This is not an off-the-shelf product you download and install today. There is no trial account and no ready-made bundle sitting on a shelf. Every build is scoped against your account, because rental rules — proration, rate steps, what counts as billable downtime — differ meaningfully between businesses and a generic implementation would be wrong for most of them.