Issue a Signed DCC When Your OEM Rejects the PDF

The email came from the customer’s supplier-quality portal, not from a person: effective next quarter, calibration evidence for delivered parts must be submitted as a Digital Calibration Certificate. PDF attachments will be flagged as non-conforming. The quality manager who forwarded it to you had one question — the same one you are probably asking now: we don’t run an accredited lab, so how are we supposed to issue a DCC at all?

That question hides a smaller, more answerable one. Your OEM customer is not asking you to become a national metrology institute. They are asking you to stop sending them a document they have to re-key, and start sending them structured evidence their own system can ingest. Those are very different requests, and the second one is inside reach for any team that already keeps a clean calibration record.

What the customer is actually demanding

A PDF certificate is a picture of data. It is human-readable and nothing more. When your customer receives one, someone on their receiving-inspection team opens it, reads the as-found and as-left values, the tolerance, the uncertainty, the calibration date, and the traceability statement, and types all of it into their own quality system. Every transcription is a chance to invert a sign, drop a decimal, or paste last year’s value. At volume, across dozens of suppliers, that manual step is exactly the failure mode their auditors keep finding.

A Digital Calibration Certificate removes the typing. The PTB/EURAMET DCC schema — current release v3.3.0 — is an XML format that carries the same information as your PDF, but as validated, addressable data. It splits the certificate cleanly in two. The administrativeData block holds the identity: which instrument, which serial number, which customer, which calibration date, which responsible party. The measurementResults block holds the metrology: the measured quantities, the as-found and as-left values, the tolerance, and the uncertainty. Units and values are expressed through the D-SI framework — the digital SI — so a length is not the string "12.001 mm" but a machine-typed quantity with an SI unit, a value, and an associated uncertainty the receiving system can read without guessing.

That structure is the whole point. When your customer ingests your DCC, the as-found value lands in their as-found field because the schema said so, not because a technician decided it looked like one.

The signature is what makes it evidence

Structured data alone is not trustworthy — it is just easier to edit. What turns a DCC into evidence a customer’s auditor will accept is the digital signature wrapped around it, typically an XAdES signature over the XML. It does two things: it proves the certificate has not been altered since you issued it, and it binds it to the issuer. A DCC can also embed a PDF/A-3 rendering inside the same file, so a human can still open and read it while the authoritative content stays in the signed XML. The PDF didn’t die; it moved inside the certificate as a courtesy copy.

This is where ISO/IEC 17025, ISO 9001 clause 7.1.5, and ISO 10012 all point in the same direction: measurement evidence has to be identifiable, retained, and protected from loss or alteration. A signed DCC satisfies that far more convincingly than a PDF that anyone with a pdf editor could quietly change.

Where PrüfDesk fits — and where it stops

Here is the boundary, stated plainly, because getting it wrong is how teams over-promise to an auditor. PrüfDesk is the system-of-record for your equipment, its calibration status, and its evidence. It does not perform the physical calibration, and it does not manufacture traceability to a national metrology institute. Traceability comes from whoever actually calibrated the instrument — your accredited external lab, or your own qualified internal process — and it lives in the record because that lab put it there.

What PrüfDesk does is hold that record faithfully and hand it back out in the shape your customer now requires. An instrument’s calibration record already contains the structured facts a DCC needs: the unique instrument identity, the calibration and due dates, the as-found/as-left values, the tolerance, the uncertainty statement, the pass/fail result, and the traceability reference captured when the certificate was logged or ingested. Exporting a DCC is a matter of mapping those existing fields into the schema’s administrativeData and measurementResults blocks, validating against the v3.3.0 XSD, and signing the result — not inventing anything new.

Consider a 25 mm digital micrometer you supply calibration evidence for. Its record holds an as-found reading against a 25 mm gauge block, an as-left after adjustment, the tolerance band, and an expanded uncertainty with its coverage factor. Today you print that as a PDF and your customer re-keys four numbers. Issued as a DCC, those four numbers travel as typed quantities with their units and uncertainty attached, wrapped in a signature, ready to be ingested into the customer’s system with zero transcription. The value they query next year is the value you signed — not a copy of a copy.

A short readiness checklist

Before you promise a customer machine-readable evidence, confirm the record behind it is actually export-ready:

• Identity is unique and unambiguous. Each instrument resolves to one record, one serial number, one identifier — so the DCC’s administrative block points at the right unit.
• As-found and as-left are stored as values, not prose. If they live in a free-text note, they cannot map into measurementResults.
• Uncertainty is captured as structure, with its coverage factor and probability — not truncated into a "± 0.3" string that loses its meaning.
• Traceability is recorded at the source, carried from the calibrating lab’s certificate, and marked as such — because you are passing it through, not asserting it.
• The output validates and signs. A DCC that fails the v3.3.0 XSD or arrives unsigned is not evidence your customer’s portal will accept.

Start with one instrument

You do not have to convert your whole crib on day one. Pick a single instrument type your OEM customer already asks about, confirm its record carries clean structured values, and export one DCC. See it ingested on their side with no re-keying. That one working exchange tells you more about your readiness than any policy document will — and it is a far calmer place to be than the quarter your customer’s portal starts rejecting PDFs.

If you want to see how PrüfDesk keeps as-found/as-left, uncertainty and traceability queryable so structured export is a step and not a project, it is worth a look — at your pace, against your own instruments.