Calibration due date tracking that does not live in a spreadsheet

The reliable way to track calibration due dates is to put the date on the asset record itself, and have the system that hands out the instrument check that date at the moment of issue. Everything else in this article is detail. The spreadsheet method fails not because anyone forgets to type the dates in, but because the dates live in one place and the instruments get picked up in another, and nothing connects the two at the moment that matters.

If you run a QA department or a lab, you know the setup this replaces. The instruments are on an asset register somewhere. The calibration certificates are in a filing cabinet, or a shared drive with a folder per year. The due dates are in a spreadsheet that one person maintains and everyone else forgets exists. All three are honestly kept, and none of them can stop an expired caliper from walking out of the crib on a Tuesday morning. The audit becomes the discovery mechanism, which is the most expensive possible place to discover anything.

Where the date should live

In Asset Basic, the calibration data sits directly on the asset record, next to the tag binding, the holder and the location. Each instrument carries a Calibration Interval in days and a Calibration Due Date, and from those two the system derives a status: Valid, Expiring Soon once the due date enters the warning window, or Expired once it passes.

Two things about those fields are deliberate. You set the interval yourself, per instrument, because a torque wrench on a production line and a reference gauge in a temperature-controlled room do not live on the same cycle, and no software should pretend to know your cycle for you. And the due date is a plain date a person entered, which means the system is only ever as truthful as your last entry. What changes is not the honesty of the data. It is where the data sits, and what gets to read it.

The warning that matters fires at pickup

Here is the part the spreadsheet can never do. When someone stands at the workstation and tries to borrow an instrument, the borrow flow reads the calibration status on that record, right then. An instrument past its due date is blocked from checkout by default: the workstation refuses the borrow until a new calibration is recorded. If a hard block does not fit how your floor works, the expired action is a policy you set in Settings, Alert Rules, block or warn. The warning window is yours to tune too, it defaults to fourteen days before the due date.

Read that against the failure it prevents. In the spreadsheet workflow, the person picking up the instrument has no reason to open the spreadsheet, so an expired gauge gets issued by someone who had no way of knowing, and used in good faith for a week. Here, the check happens at the only moment it can still change the outcome, and it is performed by the system that was already part of the transaction. Nobody has to remember anything, which is the only kind of process that survives a busy floor.

One screen for the person who owns calibration

Whoever owns the calibration schedule gets a dedicated Calibrations page with two tabs, Expiring Soon and Expired, sorted by urgency, with days left against each instrument. The column that earns its place is Holder: an overdue instrument that is out on loan shows the name of the person who has it. That turns "we have three overdue instruments" from a search into a phone call, because the question "where is it and who do I chase" is answered on the same row.

The rest of the loop is one button. When an instrument comes back from calibration, Record Calibration, on the Calibrations page or on the asset's detail panel, resets the cycle and the instrument can be issued again. The certificate from the lab is stored with the calibration history on the record, and a setting can require one before a calibration counts as recorded, so the paper trail builds itself in the same motion. No separate filing step, no folder per year.

The same status shows up everywhere the instrument does: a Calibration Due tile on the dashboard, a colour-coded calibration column on the Live Board next to who currently holds each tool, and the calibration state on the asset row itself.

When the auditor arrives

The audit question is always some form of "show me every instrument, its due date, and prove the overdue ones were controlled". In Reports, the Calibration Due tab lists each instrument with its due date, days to due, overdue ones counting in negative days, and the current user, exportable in one click. The transaction history sits alongside it, so who borrowed an instrument and when is on record too.

What was a week of assembling evidence becomes an export. Careful with the claim, though: the system does not make you compliant, and this article will not tell you what your auditor requires, because that depends on your standard and your assessor. What it changes is the mechanics. The evidence exists as a report instead of as an archaeology project.

Where RFID fits in this

Everything above works because each instrument is one record, and the record is trustworthy. The RFID tag is what anchors the record to the physical object: bound once at the desk on the AZD-R1 reader, the tag makes the instrument identify itself at the workstation, so the calibration check runs against the right record every time rather than whichever row someone picked from a list. Steel instruments deserve one caveat here, a plain label flat on a metal surface will disappoint, and the on-metal article covers what to use instead.

The tag also helps with the instrument that is due next week and not in its drawer. An asset carries its last seen location, and a handheld can be sent to find it, which beats asking three shifts whether anyone has seen the reference caliper.

What this does not do

Honesty section, because a tool that stores dates gets oversold easily. The system does not choose calibration intervals, that is your metrology decision. It does not perform, schedule or outsource the calibration itself, it is not a CMMS and not a calibration lab, and Record Calibration documents an event rather than certifying it. The block at the workstation is a policy you chose, not a law of physics, someone with admin rights can change it, which is exactly as it should be. And the whole structure is only as good as the habit of recording calibrations when they happen, the difference from the spreadsheet is that here the habit has a button, a required certificate if you want it, and a system that notices when the habit slips.

Setting it up

The setup is deliberately small. For each instrument that needs it: open the asset, Edit, set the interval in days and the current due date. Then two decisions in Settings, Alert Rules: what happens on expired, block or warn, and how many days of warning you want. That is the whole configuration. From there the Calibrations page fills itself, the workstation starts checking, and the first report is ready the same day.

If your instruments are not tagged yet, that part comes first, create the records, bind the tags, and a first spot check will tell you whether the register you just built matches the room. The calibration layer then rides on records you already trust.

The Tuesday morning version

The test of any calibration workflow is not the audit, it is an ordinary Tuesday: a technician at the workstation, badge in hand, reaching for a gauge that went out of calibration over the weekend. In the spreadsheet workflow that gauge gets used, and the finding gets written up months later. Here the workstation says no, the Calibrations page already had the gauge on its Expired tab, and the person who owns the schedule knew before the technician did. The spreadsheet was never the problem. The distance between the spreadsheet and the doorway was.

TRAKON is built and supported by ACCUZ® Industries.