How contract billing works

A managed print or equipment rental agreement is really two agreements wearing one coat. The customer pays a fixed amount for having the device — the rental, the management fee, the base service cover — and a variable amount for what they actually put through it. BMS bills both on a single invoice, but it cannot calculate them at the same moment, because it knows one of them a month before it knows the other.

Nearly every date, status and setting on the billing screens follows from that one fact. This document explains the machinery underneath it.

The two clocks

Open any billing period in BMS and you will find two date ranges side by side, and they do not match.

The base period is the span the fixed charges cover. It normally runs forward: a period due at the end of April covers the rental for May. This is billing in advance, and it is what the customer expects — they pay at the start of the month for the month they are about to have.

The usage period is the span the metered charges cover, and it runs backward: the same period bills the copies counted during April. It has to, because nobody knows April's count until April is over.

So a single transaction routinely reads:

Rental Charge for 01/05/2026 – 31/05/2026 — $110.00 Usage – Black, for 01/04/2026 – 30/04/2026 — 1,081 @ $0.009664 Usage – Colour, for 01/04/2026 – 30/04/2026 — 2,262 @ $0.096631

Two different months, one bill. This is not a fault, and it is the single most common thing to have to explain to a customer looking at their invoice.

How far each clock is offset is set on the contract, not hardcoded. Fixed charges can be billed with no advance at all, one month in advance, or two. Usage can be taken from the current month or the previous one. A third range, the recon period, appears on contracts that settle minimums over several months at once; it is explained in About reconciliation.

Why billing periods exist ahead of time

BMS does not decide what to bill when the bill is due. It lays out the contract's entire schedule in advance — a five-year monthly agreement gets sixty billing periods, numbered Billing 1 of 60 through Billing 60 of 60, each with its dates already set.

This is deliberate, and it buys three things. You can see a contract's whole future and its whole past on one screen. You can tell immediately whether a month has been billed, is about to be, or was skipped. And when a contract is varied or terminated mid-term, BMS has something concrete to cancel and replace rather than having to reason about what would have happened.

The first period of a contract is normally an advance period — it bills the fixed charges only, because there is no usage history yet. Everything after it is cyclical: fixed charges forward, usage backward, month after month. When a contract ends, a final termination period settles whatever is outstanding.

A contract that runs past its contracted expiry does not simply stop. It moves to an ongoing state and BMS keeps adding periods month by month until somebody terminates it. This matches how these agreements actually behave — equipment stays on site and keeps printing long after the paperwork expires — and it is why you will see contracts numbered Billing 62 of 60.

From period to transaction

A billing period on its own holds no money. It is a slot: dates, a sequence number and a status. The money lives in the transaction generated against it, and the gap between the two is where a person gets to intervene.

Transactions are generated ahead of the due date, not on it. The lead time is a system setting; while a period is waiting, it sits at Pending and tells you plainly when its transaction is due to appear and offers to generate it now if you cannot wait.

Generating early is the normal way to get a look at a month before the automated run reaches it.

When the transaction is generated, BMS builds its lines from the contract's charges:

• Fixed charges become lines directly, priced from the contract's rates for the base period.
• Metered charges become usage lines. Each one needs a start and an end reading for every meter on every asset attached to that charge; the difference is the volume, and the volume is priced against the rate card.

Because the second kind depends on readings that may not have arrived, a transaction tells you its reading progress in plain terms — 1 of 1 assets read, 2 of 2 meters read (manual) — and separates automatic readings from manual ones, so you can see at a glance whether a device is reporting for itself or whether someone has to go and ask.

When the readings do not arrive

They often do not. A device drops off the network, a collector agent stops reporting, a customer ignores the meter request email. BMS will not simply refuse to bill, because a missed month compounds: skip April and the customer gets a double bill in May.

Instead it classifies the transaction and applies a policy that depends on what the contract actually promises:

• If nothing is missing, the transaction bills what was measured.
• If the contract has no minimum volume, BMS estimates from the contract's own rolling averages. There is no committed number to fall back on, so the best available answer is what this customer normally does.
• If the contract has a minimum but does not reconcile, BMS bills the minimum. The customer owes that much regardless of usage, and because nothing is ever settled retrospectively on such a contract, billing the minimum is both defensible and final.
• If the contract has a minimum and does reconcile, BMS bills zero usage. This looks alarming and is in fact the safest answer: the reconciliation at the end of the cycle works from cumulative counters, so the real volume is picked up as soon as a reading arrives. Guessing now would have to be undone later.

The logic is worth understanding rather than memorising, because it explains why two contracts with the same missing reading are billed differently. BMS is not being inconsistent; it is applying the only fallback that each contract's own terms make defensible.

Review, release, invoice

Once a transaction exists it can be looked at, and this is the point of the whole design. A transaction is open while it is still yours to change: you can enter readings, request them, add a line, adjust a quantity, or put the transaction on hold so that it is deliberately excluded from this month's run while a query is resolved.

Releasing a transaction is the moment of commitment. It says the numbers are right and the bill can go to the customer. Release is reversible up to the point an invoice is generated, and after that the correction path is a reversal or a rebill rather than an edit.

Splitting release from invoicing rather than doing both at once is what makes the monthly run manageable. Hundreds of transactions can be checked and released as they are cleared — in bulk, filtered by billing group — and invoices generated afterwards in one operation, with the certainty that everything being invoiced has already been looked at.

Why the work is grouped

Contracts carry a billing group, and the billing screens are filtered by it throughout. This is not cosmetic. Different groups settle differently: some are funded by a finance company that must be paid on its own schedule, some are in-house, some are pure meter plans. Grouping keeps the review work coherent — one person can take one group, apply the judgement it needs, and release it — rather than presenting a month's billing as one undifferentiated list of several thousand rows.

What this costs you

Every design has a price, and it is fair to name this one's. A reader looking at an invoice must cope with two date ranges. A new member of staff must learn that Pending means "no transaction yet" rather than "awaiting approval". A contract that ran past its expiry keeps generating periods until somebody notices, which is forgiving if the equipment is still out there and untidy if it is not.

The alternative — calculating everything at the moment of invoicing — would be simpler to describe and considerably worse to operate. It would offer no place to catch an error before the customer sees it, no way to see a contract's future, and no defensible answer for a month where a meter never reported. The extra machinery is what turns billing from a monthly leap of faith into something you can check.