Certification Body Audit Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does trying to cover every scheme in the first release go wrong so often?

A body holding ISO/IEC 17021-1 for management systems, ISO/IEC 17065 for a product scheme and ISO/IEC 17020 for inspection can describe all three in a single meeting, so all three end up in the scope of release one. That is the failure. Those standards carry three different competence models, three different duration or inspection effort methods, three certificate formats and three sets of accreditation obligations. They are not variations on a theme, they are three products sharing a client list.

What happens next is predictable. Discovery for scheme one finishes and the team starts scheme two, at which point the reduction limits turn out to work differently and the decision authority sits with a different role. The 12 to 18 week first release becomes nine months, the scheduler is still in the spreadsheet, and the budget that should have bought the second phase has been spent proving that the data model was wrong.

The fix is unpopular and it works. Pick the scheme with the most certified clients. Ship the client and scope register, competence and impartiality aware scheduling, and audit duration calculation for that scheme alone, and put the scheduler in it on day one. Then add scheme two. If scheme two needs code rather than configuration, your model was wrong and you have found out for the price of one scheme instead of three.

What goes wrong when you migrate the competence matrix and the client scope register?

The competence matrix is almost never a clean data source. It is the technical manager's working document, and the cells contain things like a tick, a tick with a note about a witnessed audit in 2019, and the word pending. Sector codes are free text, so metal fabrication appears three ways. Witness evidence lives in a folder rather than against the cell.

The scope register has a different problem. On most projects we find a meaningful share of certificates whose printed scope wording does not exactly match the scope recorded in the register, which in turn does not exactly match the wording in the decision record. Nobody was careless. The certificate was produced from a template, the register was updated later, and the decision minute used shorthand. Once you build a system that generates certificates from the decision record, those disagreements have to be resolved before go live, and each one is a technical review rather than a data entry job.

Treat it that way in the plan. Load clients, sites, scope items, schemes and cycles first. Keep historical findings in summary form and leave the paper record where it is, because migrating ten years of report documents rarely earns its cost. Then run a reconciliation report that lists every disagreement between certificate wording, register wording and decision wording, and make the technical manager sign off each one. Budget days for that, not hours.

Why do scheme owner submissions and finance integrations break after launch?

These are the two integrations that matter in a certification body and they break for different reasons. Scheme owner data submission breaks because the format is owned by somebody else and changes on their schedule, not yours. A build that hard codes the file layout works until the scheme owner adds a column, at which point your monthly submission fails silently and you find out when they chase you.

Finance breaks because the accounting package thinks in invoices and your business runs on audit days. A client adds a site in month seven, the system correctly recalculates the remaining programme and lengthens the surveillance, and the invoice for that surveillance went out three weeks ago at the old duration. Now you either absorb the difference or have an awkward conversation, and both happen quietly until someone reconciles a quarter.

The fixes are unglamorous. Model each submission format as versioned data with an effective date and run a validation pass before you send, so a rejected file becomes a queue item rather than a surprise. Reconcile submissions monthly rather than at renewal. On the finance side, make the audit day the billable unit inside your system and post to accounting from there, then have any recalculation of a quoted audit raise a flag for a human rather than adjusting silently. The recalculation is correct. The silence is the problem.

What happens when the accreditation evidence trail is not covered?

An assessor samples ten audits and asks the same five questions of each: how was the duration derived, what evidence shows the assigned auditor was competent for that scope, how was impartiality checked, how were the findings closed, and who made the certification decision. If the system was not designed to answer those questions per audit, the data usually exists but in fragments, and assembling it means a person opening five screens and a folder.

Retrofitting the trail is the expensive version. Provenance cannot be added to records that were written without it, so you end up backfilling by hand for the sampled audits and hoping the sample is small. Bodies that have been through this once tend to insist on it the second time.

The fix is to design the assessment screen before you design anything else. Every write records who did it, when, and which rule version applied. Duration stores its derivation, not just its result. Competence assignment stores the matrix state at the moment of assignment rather than the current state, because the auditor's qualifications may have lapsed since. Finding closure stores the reviewer identity and the timestamped verdict. Then the answer to any sampled audit is one screen, and the assessment becomes a conversation instead of a search.

Should you build custom or configure what you already own?

For a good number of readers the honest answer is configure. Intact Platform is a genuine purpose built product for this category, covering audit planning, checklists, findings and certificate lifecycle for management system schemes. If you run one or two mainstream schemes with conventional rules and roughly 150 certified clients or fewer, configure it properly, spend the difference on auditor recruitment and technical review capacity, and revisit the question in two years.

There is a second reason to configure first even if you expect to build later. Configuration forces you to write down the rules that currently live in your technical manager's head: the reduction justifications, the sector code mapping, the scheme specific exceptions. That written record is the single biggest determinant of how long a custom build takes, and producing it inside a packaged tool is cheaper than producing it inside a discovery phase you are paying for by the week.

The build case starts when you hold several accreditation standards at once, when configuration effort in the packaged tool has become somebody's permanent job rather than a setup task, when scheduling depends on one person who cannot take leave without risk, or when an accreditation assessment has already produced a finding about audit programme control. Those are the conditions where a product built for the common case stops helping.

How do hidden costs get into the quote?

Five items account for most of the overrun in this category. Additional schemes, which are quoted as a percentage uplift and behave like separate projects because each scheme owner rulebook needs its own validation. Offline auditor reporting, because auditors work in factories and basements with no signal and sync conflict handling is real engineering rather than a checkbox. Multiple accreditation bodies, because their evidence expectations differ and you will be building to the strictest. Certificate production, because accreditation marks are used under licence with rules about size, placement and wording that nobody mentions until the first certificate is printed. And the competence matrix migration described above, which arrives as a data task and turns into a technical review.

The way to keep them visible is to price them separately. Ask for each scheme as its own line, offline capture as its own line, and each accreditation body's reporting as its own line. Ask explicitly for a parallel run in the plan, because running scheduling in both systems for a full month is how you discover the unwritten rules, and a quote without it is a quote that will need a change request. A proposal that presents one number for a multi scheme body has not been thought about.

What separates a build that works from one that fails here?

The working ones share a data model. Client, site, scope item, scheme, cycle, audit, auditor assignment, finding, evidence, decision and certificate are separate objects. Competence is a matrix with expiry rather than a field on the auditor record. Duration is computed from inputs and stores its derivation rather than being typed by a scheduler. Certificates are generated from the decision record so the two cannot diverge, and suspension and withdrawal are state changes that update your public register immediately.

The failing ones almost always share one of two shapes. Either the developer drew customers, jobs and documents, which is a services CRM (Customer Relationship Management) and will discover accreditation on your budget. Or the scope covered every scheme at once and nothing reached the scheduler until month seven, by which point the people who were going to use it had stopped believing in it.

The practical test before you sign anything is to ask how a mid cycle scope change is handled, because that single scenario touches sampling, duration, programme, certificate and invoice at once. If the answer is that an administrator re enters things, the problem has not been understood. Ask the same question about a lapsed witnessed assessment, and listen for whether the system blocks the assignment or reports it afterwards. Blocking is the whole point.