# Service Contracts and Call-Offs: How to Measure and Bill Work That Has No Fixed Units
TL;DR: a framework agreement fixes the rules and rates, a call-off activates and caps a specific piece of work within those rules, and the field ticket is the on-site proof that ties that work to an invoice — trying to run all three as if they were a quantity-based purchase order is the most common cause of billing disputes in oilfield services contracts.
The problem: a service isn't a warehouse part
A classic purchase order assumes a simple equation: agreed quantity × unit price = amount payable. You buy 200 valves at a unit price, 200 valves arrive, you check the delivery note, you approve the invoice. That's the "three-way match" — PO, receipt, invoice — that any procurement ERP handles well.
Oilfield services rarely fit that equation. A wireline crew billed by the day, an instrumentation technician called out per event, a crane rented by shift, a structural integrity inspection billed per delivered report — none of these has a "quantity" that can be fixed before the work starts. The number of days depends on what's found downhole. The number of events depends on how often equipment fails. Shift duration depends on offshore weather.
When an operator or an EPC tries to force this kind of work into a procurement module designed for physical goods, the usual result is one of two extremes: either someone overestimates an "estimated quantity" of days just to get a closed PO into the system — triggering a dispute every time it's exceeded — or billing runs "open-ended" with no ceiling at all, which defeats the entire point of a budget commitment. Neither is contract management; it's bookkeeping trailing behind the supplier.
Three layers, three different jobs
The way this actually gets solved in practice isn't one document — it's three, each with a distinct function and its own lifecycle.
1. Framework agreement (Master Service Agreement)
The framework agreement fixes what doesn't change month to month: the rate card (day rate, hourly rate, per-event rate), payment terms, SLAs, penalties, currency and indexation, local-content clauses, liability and insurance. It commits no budget and generates no invoice by itself. It's the "agreement on how we're going to work," typically running one to three years with automatic or negotiated renewals.
In data terms, the framework agreement is the parent entity: it holds the rate_card_id, the base currency, the supplier, and the approval rules that every call-off underneath it will inherit.
2. Call-off (call-off order)
The call-off is what activates real work within the framework. It specifies the scope ("integrity inspection of production line X"), the validity period, the applicable rate (inherited from the framework agreement, or a negotiated variant for that specific request), and — this is the central point — a budget ceiling, not a fixed quantity. The call-off says "I authorize up to USD 180,000 of this type of work, within this period, at this rate," not "I authorize 12 days of work."
That distinction looks subtle but it completely changes the data model. A quantity-based PO closes when the quantity received matches the quantity ordered. A ceiling-based call-off closes when the accumulated consumption of approved field tickets hits the ceiling, when the period expires, or when someone closes it manually — whichever comes first. It's a counter that counts down, not a list that gets checked off.
3. Field ticket / service sheet
The field ticket is the on-site evidence: date, hours or events, equipment and personnel involved, description of the work, and the signature of whoever was on-site — normally an operator or EPC supervisor, not the supplier itself. This document, not the invoice, is what constitutes proof that the work happened as described.
An approved field ticket should be the only thing allowed to draw down a call-off. Without that discipline, any supplier can bill against an open call-off with nobody having confirmed, in real time, that the work was actually done.
| Layer | Question it answers | Budget commitment | Issuance frequency |
|---|---|---|---|
| Framework agreement | At what rates and terms do we work with this supplier? | None | Once, with renewals |
| Call-off | How much do we authorize spending, in this scope, in this period? | Budget ceiling | Per project, well or period |
| Field ticket | What was actually executed, and who confirms it? | Actual draw-down against the ceiling | Daily, per shift, or per event |
Why the quantity-based purchase order fails here
A traditional procurement system answers three questions: what was ordered, what was received, what was invoiced — and reconciles the three. Applied to a day rate, this collapses immediately:
- There's no "receipt" of a day of work. A valve is physically received; a 12-hour shift isn't confirmed the same way. The only possible confirmation is a signature on the field ticket, which requires an approval workflow, not a warehouse goods-receipt entry.
- The final quantity is only known at the end. If the PO fixes "10 days" and the job takes 14 because of a well complication, the system forces a retroactive PO change — usually after the work has already been done, which inverts the logical order of authorization.
- Events and standby aren't comparable units. A standby rate (equipment idle but contractually accruing cost) isn't the same unit as an active-operation rate. A single-quantity model has nowhere to put that second rate without artificially duplicating the PO line.
- Mobilization is a one-off cost, not a recurring one. Mobilization/demobilization fees don't scale with days worked; they're one-time events within the same call-off, and a quantity-based PO tends to mishandle them as just another "unit" at the same unit price as the recurring work.
The cumulative effect is predictable: finance teams receiving supplier invoices for services with no systematic way to validate them against what was actually authorized, beyond looking at the invoice and trusting it. That's exactly where the approval automation described in Automated Procurement in Angola comes in — but applied to a ceiling-and-consumption model, not a quantity-and-receipt one.
Connecting this to the budget and to the invoice
The call-off doesn't live in isolation — it needs to connect to something above it and something below it.
Above: on capital projects, the call-off should draw down against an Authorization for Expenditure (AFE) or against the approved operating budget for that well or facility. Without that link, it's possible to authorize call-offs that, added together, exceed the approved capital ceiling for the project without anyone triggering an alert — the same structural problem described in AFE and Capital Control, here applied to the services layer instead of the capital-investment layer.
Below: every line on the supplier's invoice should map to one or more approved field tickets, which in turn map to a specific call-off, which in turn maps to a line on the framework agreement's rate card. When that chain exists in the system, validating a services invoice stops being a manual PDF read and becomes a query: sum of approved field tickets × contractual rate = expected invoice amount. Any deviation automatically flags for review.
This traceability chain gains extra urgency with mandatory e-invoicing in Angola. Under Presidential Decree No. 71/25, electronic invoicing has been mandatory since 1 January 2026 for large taxpayers, State suppliers and anyone issuing invoices of 25 million kwanzas or more; according to EY, extension to the remaining taxpayers under the General and Simplified regimes is scheduled for 1 January 2027 (EY Angola). An electronic invoice issued through AGT-certified software still has to be justified against something on the buyer's side — and if that "something" is a call-off with a ceiling and approved field tickets, reconciliation is straightforward. If it's just a verbal promise of rate and term, the electronic invoice only automates the problem, it doesn't solve it. VAT treatment, at the general rate of 14% on most services rendered (Law 7/19, as amended by Law 14/2023 — CMS), applies to the value of this validated invoice, not to an estimate.
A worked example
Consider a wireline crew contracted for one-off interventions on a platform. The framework agreement fixes: a daily operating rate, a daily standby rate (lower), a fixed mobilization/demobilization fee, and a 48-hour response-time SLA after call-out.
For a specific intervention, the operator issues a call-off: scope "wireline intervention on well P-14," 30-day period, a budget ceiling covering an estimated 8 days of operation plus a 4-day standby contingency margin, plus mobilization.
On site, the operator's supervisor signs daily field tickets: day 1-2 mobilization, day 3-9 operation (7 days, not 8 — the intervention went faster than expected), day 10 one standby day for bad weather before demobilization. Each ticket enters the system, draws down the call-off at the rate matching that day's type, and the ceiling balance falls in real time.
At close-out, the supplier's invoice should sum exactly: mobilization (1×) + 7 operating days + 1 standby day, at the framework agreement's rates. If the invoice arrives showing 8 operating days, the system already knows, before anyone opens the PDF, that there's one day short of an approved field ticket to support that line.
What this requires from the system, not just the process
None of these three layers works reliably in a spreadsheet shared over email — that's exactly the scenario described in Getting Off Spreadsheets, where the point of failure isn't people's intentions but the absence of a single, auditable record of what was authorized, consumed and invoiced. An ERP built for this domain needs to model the call-off explicitly as its own entity — with a ceiling, a running balance, a validity period, and a link to the AFE or the operating budget — and the field ticket as the only event allowed to draw down that balance, with an approval workflow and an audit trail.
This kind of domain-specific modeling — not a generic procurement module bent into shape — is what makes the difference between a system finance trusts outright and one finance has to re-check line by line. Wise Hustlers is building its own energy-sector ERP, Enerxia — which has no client in production yet — covering upstream, wells, production, projects and contracts, procurement, suppliers, inventory, MRO, maintenance, fleet, logistics, HSE, quality, HR, training, finance, tax and compliance — and this kind of contract-modeling problem, among others, is why we build custom software instead of forcing a generic procurement module to pretend that services have fixed units.
FAQ
Does a call-off always need a framework agreement behind it?
From a risk-management standpoint, yes — without a framework agreement there's no agreed rate card or general terms, and every call-off would have to renegotiate all of that from scratch. Technically, a system can allow "standalone call-offs" for one-off suppliers, but that should be a documented exception, not the default pattern.
How do you handle a field ticket that pushes past the call-off's ceiling mid-job?
The system should block or flag new tickets once projected consumption approaches the ceiling — from a threshold the operator sets itself (for example, 80%) — forcing a conscious decision: raise the call-off's ceiling (with fresh approval) or stop the work. What shouldn't happen is a field ticket being silently accepted past the ceiling and only showing up as a problem on the invoice, weeks later.
Does the field ticket replace the supplier's invoice?
No — they're different documents with different owners. The field ticket is signed by whoever is on-site, on the client's side, and confirms the physical fact of the work. The invoice is issued by the supplier and claims payment. Invoice validation is precisely the comparison between the two, plus the contractual rate.
Does this only apply to offshore operations?
The pattern is the same for any service billed by time or by event rather than by unit — onshore maintenance, transport by shift, training per session, consulting per day. Offshore is where exceeded ceilings cost more and faster, but the underlying data model is identical onshore.