Work Orders in QuantX Ops: The Customer PO as the Backbone

Ask a project manager what a job is worth and you get the contract value. Ask accounts and you get what has been invoiced. Ask the site team and you get what has been done. In most companies those three numbers are never written down in the same place, which is why they are never the same.

In QuantX Ops the work order holds all three.

What a work order carries

Figure	Meaning
Ordered	The contract value — what the customer agreed to pay
Billed	Issued tax invoices against it, net of GST and of any credit notes
Received	Money actually banked
Still billable	Ordered less billed — what you may still raise

Billing past the order

This is where most systems make the wrong choice. Billing more than the customer ordered happens constantly and for good reasons: extra scope done on instruction, a rate revision agreed late, a variation everybody accepted verbally and nobody has papered yet.

A system that blocks it teaches people to raise that invoice outside the system, where nobody can see it at all. So QuantX Ops permits it — and says so, in amber, every time:

This bills past the order. WO-0001 was ordered at ₹9,94,000. This takes the total billed to ₹10,50,000 — ₹56,000 more than ordered.

The button changes from Raise draft invoice to Raise invoice anyway. You proceed knowingly, or you go and get the variation signed. What you cannot do is overrun without noticing.

Milestones are objectives, not permissions

A project's billing schedule lists what your team undertook to deliver and by when. In QuantX Ops these are objectives — for your own evaluation of the job. They do not authorise billing and they do not cap it. An objective past its date with the deliverable unfinished is flagged as a delivery problem, which is what it is.

Next: Invoicing — part billing, GST, and never billing twice.