/* case study · data analysis */

Iris Waves MPS Billing System

Turning inconsistent, manually-recorded printer meter readings into a validated, auditable monthly billing dataset.

Role:Data Analyst (modeling, business rules, reporting)Domain:Managed print services billingMethod:Rule-based calculation engine
4
print categories per machine / month
3
discount models supported
2
core datasets

Business question

Before any of this was code, it was a spreadsheet, and a monthly ritual of pain. Each month meant re-deriving "this reading minus last month's reading" for every machine by hand, across four print categories, at rates that differ per client and per machine, then applying one of three discount structures. No consistent check for a typo. No way to see, before invoices went out, which machines were simply missing a reading. The interesting realization was that this was never really a calculator problem. It was a rules problem: what does this business actually bill by, and how do I encode it so the same input always produces the same correct, explainable output?

Business rules encoded

Usage = current − prior month reading, per category
Missing prior reading is treated as incomplete, not zero.
Negative usage flagged as an error
Meter reset or typo; row is excluded from billing, not silently absorbed.
Flat discount capped so bill never goes below zero
A discount can reduce a bill to ₹0 but never invert it.
Free-pages allowance is a depleting bucket
Allocated in priority order (B&W before Colour, A4 before A3), not a naive proportional split.

Design rationale (the why)

Why encode rules in code, not a spreadsheet?
A spreadsheet formula drifts. Someone tweaks a cell, a copy-paste breaks a reference, and next month's logic quietly differs from last month's. Encoding the rules once, explicitly, means every month runs identically and every number is traceable to the rule that produced it.
Why flag negative usage instead of absorbing it?
A new reading lower than the last almost always means a meter reset or a data-entry error, never real negative printing. Silently including it produces a nonsensical bill; flagging and excluding it surfaces the problem before a client ever sees it.
Why model free-pages as a depleting bucket?
A 'free pages' allowance isn't a flat percentage. It has to be spent against specific categories in a defined priority order (B&W before Colour, A4 before A3) to match how the business actually intends the credit. A naive proportional split would produce a materially different, and wrong, bill.

Validation output

billing.iris-waves.local/validation
Serial No.UsageStatusAmount
XRX-FC-0017,000Valid₹18,420
XRX-FC-0024,500Valid₹9,215
XRX-FC-003Missing reading₹0 (excluded)
XRX-HM-011−1,200Failed validation₹0 (excluded)
Illustrative reconstruction (demo data)

Billing dashboard

billing.iris-waves.local/dashboard
Total Monthly Bill
₹28,910.00
June 2026
Clients Completed
1 / 3
33%
Machines Completed
4 / 6
67%
Pending Readings
2
action needed
Client-wise
FreeCharge3 machines₹18,830Done
Hemata2 machines₹10,080Pending
Plasma Labs1 machine₹0Pending
Data status
Printers6
Clients3
Readings10
Illustrative reconstruction (demo data)

Pipeline

step 01
Raw CSV export
step 02
Column normalization
step 03
Validation & usage calc
step 04
Discount logic
step 05
Client & machine exports

The export layer also feeds a companion fleet-analytics dashboard with real computed revenue, so nothing gets re-keyed.

Outcomes

  • Billing runs from explicit versioned rules, not drifting spreadsheet formulas
  • Data-quality issues are caught at month-close, before client-facing errors
  • Every number is traceable back to a reading and a rule
  • Dataset auto-feeds a second reporting system, eliminating one manual re-entry risk

Reflection

The hardest part wasn't arithmetic; it was translating ambiguous, human billing policy into deterministic logic that a machine can run the same way every time. Getting the free-pages rule right meant sitting with how the business actually thought about the credit, not the simplest interpretation of it. Good data work is often less about the math and more about pinning down what people actually mean.

Skills & tech

Data ModelingBusiness Rule / Discount LogicData ValidationCSV ETL & Schema NormalizationTime-Series AggregationKPI Design