DCC Ingestion: When Structured Certificates Stay Stranded

A calibration-lab manager receives a supplier’s XML certificate alongside the usual PDF. The file is attached to the equipment record. Then a technician opens the PDF and types the as-found and as-left results into a spreadsheet. A second person checks the entries.

The certificate is digital. The workflow is still manual.

That distinction matters more than the file extension. In Beamex’s 7 April 2026 article, Boehringer Ingelheim’s Klaus Fickinger describes the supplier problem: “their paper or PDF certificates all look different.” He also notes that “The four-eyes principle still presents a challenge.” These are observations from a vendor-published customer account, not a measured industry-wide error rate.

For the receiving lab, the question is practical: does the DCC populate usable calibration data, or merely become another attachment?

A structured certificate is not yet an operational record

A Digital Calibration Certificate (DCC) carries machine-readable calibration information. The PTB-led DCC work associated with the European metrology community provides an XML schema; v3.3.0 is the baseline considered here.

Its administrative-data section identifies the certificate, laboratory, customer and calibrated items. Measurement results sit in a separate structure. The D-SI framework represents numerical quantities with machine-readable units and uncertainty information, rather than leaving a receiving system to interpret a printed column heading.

Digital signatures can protect the integrity of signed content and support verification of its signer through an appropriate trust process. Signatures are optional in the v3.3.0 schema: an XML file is not automatically signed, trustworthy or metrologically correct because it validates.

Those structures make ingestion possible. They do not implement it. The receiving application still needs to map supported certificate content into fields whose meaning survives storage, review and retrieval. Saving XML in a document field preserves evidence but leaves its measurement data operationally stranded.

Follow one result through the receiving workflow

Consider an illustrative torque-wrench calibration, not a customer result. The supplier reports measurements at nominal settings of 20, 60 and 100 N·m, with separate as-found and as-left series after adjustment.

At the 60 N·m setting, suppose the reported mean applied torque is 59.4 N·m as found and 60.1 N·m as left. Each has an expanded uncertainty of 0.3 N·m with coverage factor k = 2. These simplified figures illustrate data handling, not a complete calibration procedure or conformity assessment.

An attachment-only workflow retains the certificate but requires someone to reconstruct these relationships elsewhere. A shallow import might extract 60.1 and label it “result,” losing the nominal setting, measurement stage and uncertainty context.

Useful ingestion preserves the relationship between:

• The nominal setting and the reported measured quantity.
• The as-found or as-left stage and its measurement conditions.
• The numerical value, unit and associated uncertainty information.
• The stored result and the original certificate that supports it.

The difference appears later. A quality engineer investigating earlier production needs the as-found condition, not just the adjusted instrument’s final result. If both stages have been flattened into one field, the XML’s structure has been lost inside the receiving system.

Nor should the import invent a pass/fail decision. That requires the applicable tolerance and decision rule, or a correctly interpreted supplier statement of conformity. A numerical result is not itself a release decision.

The acceptance test is therefore not “upload successful.” It is whether a reviewer can retrieve the 59.4 N·m as-found result, its uncertainty context and its source without opening the PDF and transcribing them again.

Where PrüfDesk fits—and what needs demonstration

PrüfDesk is the system of record for equipment, calibration status and evidence. Its established workflows include instrument registration, calibration pass/fail records with certificates, automatically calculated calibration due dates, step-by-step procedures and reusable templates with per-unit overrides.

DCC ingestion belongs at the handoff from supplier evidence to that calibration record. The intended outcome is to populate supported fields without re-keying, while retaining the source certificate. Queryable as-found/as-left results and traceability evidence are acceptance requirements for that integration—not capabilities to assume from an upload button.

Before relying on a particular implementation, demonstrate its supported supplier files, schema versions and field mappings. The available product description does not establish universal DCC import coverage or automatic signature verification. Unsupported content needs an explicit review route, not silent omission.

Once accepted calibration information is recorded, PrüfDesk’s scheduling and configurable overdue controls support the equipment workflow: the next due date is calculated under the configured interval, and overdue equipment encounters the tenant’s hard block or soft warning. These controls do not replace technical review of the calibration.

The same boundary applies downstream. Exporting structured certificate data should preserve supported measurement meaning so a customer can use machine-readable evidence. An audit-ready PDF compliance report is useful, but it is not a DCC export.

PrüfDesk does not perform the physical calibration or assign traceability to a national metrology institute (NMI). It manages the evidence supporting the traceability claim; it does not create that chain by importing a file.

“We still need a reviewer. What have we gained?”

A reviewer remains necessary where the quality system requires one. The gain is a change in what that person checks: source meaning, exceptions and suitability, rather than independently retyping or comparing every digit copied from a page.

Removing manual transcription removes that particular error opportunity. It does not eliminate supplier errors, incorrect mappings or inappropriate decisions. An automated import can reproduce a mapping mistake consistently; that is why a supported import needs evidence, not a zero-error slogan.

ISO/IEC 17025 provides relevant requirements for laboratory reporting and metrological traceability. ISO 9001 clause 7.1.5 addresses monitoring and measuring resources, including measurement traceability where applicable. Neither should be presented as a blanket mandate to use DCC XML. Structured intake supports controlled evidence handling within that context; it does not confer compliance.

Test the receiving side before expanding the rollout

SIKA’s TP Premium documentation describes DCC generation using schema v3.3.0 and XML export to USB. It also states that receiving-system import depends on that software. Generation and ingestion are separate capabilities.

For a pilot, use one supplier and one equipment family. Ask the receiving system to demonstrate:

• Which measurement fields populate the calibration record without transcription.
• Which content remains only in the retained certificate.
• How unsupported content reaches review.
• How a reviewer retrieves a result and its supporting evidence together.

With FORCE Technology’s DCC Theme Day scheduled for 2 December 2026, this is a useful Q4 implementation question—not a regulatory deadline. Arrive with a real certificate and a demonstrated gap, rather than another general discussion of paperless calibration.

Bring one representative supplier DCC to a PrüfDesk workflow review and identify exactly which re-keying steps a supported integration can remove.