Turning an inspection certificate into a PDF does not establish which version the customer received, who approved it, or what happened after a correction. An inspection certificate issuance control system should connect the measurement record, customer specification, approval, immutable issued version, delivery event, withdrawal and retention. This guide focuses on buying and accepting that system in a Thai factory serving local and overseas customers. It provides RFP questions and FAT/SAT scenarios, including cases where the system must refuse to issue a document.
Scope: control the issued record, not just create the draft
There are two related jobs. First, data from instruments or a LIMS is assembled into a draft certificate. Second, a responsible person approves a defined snapshot and the factory issues and distributes it. Transcription errors dominate the first job. Authorisation, revision, destination, correction and retrieval dominate the second. A product demo that produces a polished PDF may prove little about issuance control.
Our article on AI generation of inspection certificates addresses draft creation from measurement data. The factory electronic forms guide addresses shop-floor capture. Here the question is how to make sure that only the approved version reaches the right customer and remains traceable afterwards.
ISO guidance on documented information recognises electronic media, but a PDF alone does not establish control. The applicable quality agreement, certification scheme, customer contract and law determine the records and retention period. Do not assume that the US FDA’s 21 CFR Part 11 applies to every factory in Thailand: the FDA explains its limited scope. Equally, a factory with regulated US products must check its actual predicate rules rather than relying on a generic software claim.
Seven breaks in a typical certificate flow
Measurement to document. If the editable measurement file and approved PDF are separate, it may be impossible to reproduce the issued value. Link the certificate to the sample, instrument, calibration state, method, operator, time and specification version. Not every raw data field has to appear on the customer PDF, but the source must remain identifiable.
Product to customer specification. One product may have different limits, units, test lists and language requirements for different customers or receiving sites. Select specifications by product, customer, destination, effective date and relevant order or contract revision. If two rules conflict, hold the issue for review rather than silently choosing one.
Pass result to release decision. A value within limits is not enough if the instrument is out of calibration, the sample is being re-tested or a concession is pending. Record numerical evaluation, hold reason and exception approval separately. An automated pass/fail calculation is an input to a quality release decision, not a replacement for the authorised role.
Approval to revision. File names such as “final2” allow the approved content and distributed content to diverge. At approval, fix the data snapshot, template version, approver identity, time and output hash. Any later correction should create a new revision. FAT should verify that the PDF is the content the approver saw.
Issue to delivery. Issuing a record does not prove that it reached a customer. Log transmission, receipt or download, failure and retry separately for email, portal, EDI or shared folder. A delivery retry should not create another issue number.
Correction to superseded copy. Deleting the old document destroys the history; leaving it available without a warning risks reuse. Mark it superseded, preserve the correction reason and link to the new version. Record which recipients were notified and when. A factory cannot erase a PDF already downloaded by a customer, so notification and portal status matter.
Archive to search. A folder organised only by year and customer is weak when a complaint begins with a lot number. Index product, manufacturing lot, shipment lot, serial or job number, order, customer, issue ID and revision. GS1 traceability guidance describes identification, capture and sharing of objects and events. Its GDTI can identify a document where cross-company document identity is useful; it is not mandatory for every certificate.
Model the issue event and its evidence
The minimum logical objects are source inspection data, specification revision, issued snapshot, approval event, distribution event and correction event. Treat the PDF as a rendering of the issued snapshot. This makes the issued record traceable even when file storage changes.
| Object | Essential key | Change rule |
|---|---|---|
| Inspection source | Sample, measurement, test, time | Retest is a new event |
| Specification | Customer, product, site, effective date, revision | Preserve previous versions |
| Issued snapshot | Issue number, revision, lot, PDF hash | Immutable after approval |
| Approval | Person, role, time, approved hash | Record delegation |
| Distribution | Recipient, channel, time, result | Retry adds an event |
| Correction | Reason, old and new versions, notice list | Old version stays searchable but invalid |
Do not equate the issue number with the lot number. One lot may require several customer-specific certificates, and one shipment may combine lots. A corrected certificate adds another version. The relationship can be many-to-many, so test it explicitly.
An effective date is another hidden choice: should the specification follow manufacture date, inspection date, shipment date or order acceptance? The answer depends on the customer agreement. RFPs should state the governing date and an exception route. Updating the master specification must not silently change an older order’s release requirements.
RFP requirements that can be tested
Specify state changes as permissions
A practical workflow may include draft, inspection complete, awaiting approval, approved, issued, delivered, superseded and awaiting reissue. The exact names matter less than the permitted action in each state. An inspector may edit a draft, but a change after submission must carry a reason. Approved values cannot be edited in place; they require rejection or correction. An issued document awaiting delivery may have its recipient checked without changing the content. Superseding a delivered document triggers a customer notification task. Apply these constraints in the API as well as the screen.
Department names alone are too broad for access control. Inspectors, supervisors and quality release managers may all sit in Quality but have different product or customer authority. A delegated approval should have a scope, validity period, requester and reason; sharing the approver’s account is not delegation. Disabling a former employee’s login must not erase the historical approval and role.
An audit record should show actor, time, object, action, reason and previous and new state. “Edited” is not enough to reconstruct an issue. Sensitive values need not be duplicated throughout logs if a secure reference to both versions is available. Keep server receipt time distinct from the time an offline plant device says an event occurred.
Separate a quality hold from a delivery failure. Conflicting specifications or expired calibration require a quality decision. Email timeout may require only a distribution retry. One generic “error” status makes it unclear whether reapproval is needed. Notify different owners, reuse the same issue number on retry, and retain the external service response ID and time so a possible duplicate delivery can be investigated. If a privileged override is unavoidable, require a reason and an authorised reviewer.
Ask vendors for an input, a condition, an expected result and an audit record for each important requirement. A “yes” beside a feature name is insufficient.
| Requirement | RFP question | Acceptance evidence |
|---|---|---|
| Separation of duties | Can an inspector approve their own result? | Role matrix and refusal log |
| Specification conflict | Does the system block issue when two rules apply? | Test record and hold reason |
| Revision | Does an approved edit create a new version? | Both PDFs and revision log |
| Delivery | Are wrong recipients and retries distinguishable? | Distribution events |
| Search | Can one lot retrieve every customer and version? | Timed search result |
| Recovery | Is a retry idempotent after network loss? | Recovery procedure and logs |
Specify retention policy, backup and recovery objectives, export format, time zone, tamper resistance of audit records, portal access expiry and access to historical versions after software upgrades. There is no universal “ISO retention period” for every certificate. Derive it from the actual agreement and applicable rules.
Thai plants may collect inspection data in Thai, issue an English certificate and seek approval from a Japanese parent office. “Multilingual” must be divided into UI, output, notification, field definitions and units. Store timestamps consistently, and convert to ICT or another display zone only at presentation. Verify whether a document date is shown in Gregorian or Buddhist Era format; do not change its underlying date.
Connect QMS, LIMS, ERP and MES without losing ownership
An existing QMS or LIMS may be the simplest route when source values and disposition already live there. Its weakness may be customer-specific distribution or ERP shipment linkage. A document management platform can be strong on approval and revision while needing extra work for lot and measurement identity. A dedicated issue service around ERP/MES is flexible for unusual customer formats and channels, but the plant and supplier then own integration and maintenance.
Choose after counting customer-specific templates, source systems, delivery channels, issue volume and cost of a wrong release. Fifty certificates per month for two specifications might fit an existing module; 5,000 per month across PDF, XML and portal delivery may require explicit distribution events and resilient ERP integration. These are illustrative situations, not vendor throughput benchmarks.
Set one system of record for each field. ERP/MES can own lot and shipment, LIMS/QMS can own test values and disposition, a controlled quality master can own customer specifications, and the issue system can own approvals and distribution. A field editable in two systems creates an accountability gap. Define update rights, API failure retry and reconciliation. The receiving and shipping inspection guide helps identify a physical shipment check point.
Cost and value: compare five-year operation, not just PDF licences
The dominant work may be integration, customer rule modelling and migration, not document generation. Request separate prices for initial build and five-year operation.
| Cost layer | Work to include | Unit for quotation |
|---|---|---|
| Data connections | Instruments, LIMS, ERP, customer master | Systems, fields, update rate |
| Rules and layout | Customer templates, limits, units | Template and revision count |
| Approval and delivery | Roles, notifications, EDI | Approval and channel count |
| Migration and retention | Indexing old PDFs, storage, search | Records, capacity, years |
| Maintenance | Customer changes, audit support, incidents | Annual change and SLA volume |
Measure time spent re-entering values, waiting for approval, resending certificates, tracing superseded copies and searching during audits. In an illustrative model, 1,000 certificates a month, eight minutes saved per certificate and labour at THB 300 per hour yield THB 40,000 a month before operating and change costs (1,000 × 8 ÷ 60 × 300). This is an example, not a TOMAS TECH customer result or a Thai market rate. Track wrong-recipient, rejected-certificate and correction counts separately rather than inventing a large “risk avoided” return.
A 90-day pilot and comparative vendor test
Before the pilot, sample recent documents and list every difference in test items, limits, units, layout, approval route and destination. Some apparent “customer” differences are receiving-site, end-use or order-revision differences. Separate contractual certificate requirements from historical attachments whose necessity is unclear. Record the source agreement and effective date for each rule.
Give every shortlisted vendor the same anonymised data: two customer specifications, a corrected measurement, a changed recipient and a network failure. Record what works as standard functionality, configuration or custom development. Include the cost of retesting customisations after product upgrades. Ask the vendor to demonstrate inspector, quality approver and distribution roles, not only administrator access.
A 90-day pilot can spend the first two weeks mapping current processes, the next month configuring two representative customers and product families, and the rest on exception tests, corrective actions and go-live decision. Ninety days is a planning example, not a universal implementation duration. Invite operators, quality, customer service, IT and the customer-facing owner. Thai and English notifications must be checked by their actual users.
FAT/SAT: deliberately trigger six failure modes
- Unapproved issue: a passing measurement without quality approval must not produce a distributable certificate.
- Specification boundary: orders either side of the effective date must select the right limit and template; ambiguous rules must hold.
- Post-approval correction: the old version remains traceable and invalid; the new version shows reason and approval.
- Wrong recipient: an attempt to send customer A’s certificate to customer B must be stopped before transmission.
- Network loss and retry: re-running a failed delivery must not create another issue number; it should add a delivery event.
- Audit search and restore: searching a lot finds every version and recipient, and a restored backup preserves hashes and logs.
FAT checks the vendor environment; SAT uses the plant’s real network, devices, people and data. Critical release conditions can be set to zero unauthorised issues, zero wrong specification selections and zero overwrites of approved versions. Search-time and throughput targets should come from actual plant volume and customer expectations, not arbitrary numbers in a demo.
Operating measures and change control
Measure the right operating indicators
Count more than issued PDFs. Split lead time into inspection completion to approval and approval to customer delivery; each delay has a different owner. Track first-issue rejection, customer resend requests, correction rate, attempted wrong-recipient sends blocked by the system and access to superseded versions. A blocked misdelivery logged by the system can demonstrate a safeguard at work. Define whether a denominator is shipments requiring certificates or certificates issued: one shipment may carry several certificates. Compare the same customer groups before and after implementation, accounting for seasonality and changes in customer mix.
Test retrieval using a realistic complaint: “the concentration on this lot’s certificate differs from the purchase specification.” A quality user should be able to move from shipment and lot to the specification effective at that time, measurement source, approver, PDF sent and correction history without vendor assistance. Current master data alone cannot reproduce the past decision. Customer access should expose the approved explanation, not internal raw records or another customer’s data. Separate internal evidence from the material shared externally.
Include post-launch change control in the service agreement. Customer test lists, limits, wording and recipients will change. Define who verifies the source request, configures the rule, tests it and sets its effective date. An urgent change must not rewrite previously issued records. Check which orders fall either side of the boundary and whether any correction is required. Define Thai-time support, escalation to the quality release owner, temporary issue conditions and reconciliation after an outage. Two similarly priced vendors can differ materially in these operating responsibilities.
Migration and cutover
Do not assume every old PDF must be recreated. Separate historic reference-only records from documents that may still need resending. Index the former by issue ID, lot, customer, date and revision while retaining the original. Confirm the status of the latter before a resend and log the new distribution event. If an old PDF lacks a revision, customer code or signer, mark it as a migration exception; never present a guessed value as established fact.
At cutover, prevent parallel issue numbers from the old spreadsheet and the new system. Define the switch time, the last issue allowed in the old process, treatment of pending approvals, emergency issue procedure and later reconciliation. If a manual fallback is needed, assign who reserves the number, authorises release, notifies the customer and records the event after recovery.
FAQ
How is issuance control different from an electronic forms system?
Electronic forms capture shop-floor data and replace paper. Issuance control governs an approved customer document: version, recipient, delivery, correction and archive. One product may do both, but test and price them separately.
Does an electronic signature allow automatic delivery?
No. Check that the signed content matches the output, the right specification and recipient were selected, and the order is not on quality hold. Signature law and customer acceptance depend on jurisdiction and contract; choose the mechanism accordingly.
What drives the cost of certificate digitisation?
Source interfaces, customer rules, approval routes, delivery channels, migration quality and future rule changes usually matter more than user count. Ask for separate initial, annual and per-change costs.
Can one issue number cover Thai, English and Japanese output?
It can if the language variants render the same approved snapshot and the quality team validates field names, units, limits and notes. Decide whether language is a rendition or separate revision. Generate variants together so one language cannot remain outdated.
Where does AI belong?
AI can assist with extracting legacy fields, classifying free text and drafting translations. Final specification selection, release authority and issuance should follow auditable rules and authorised human responsibility.
Conclusion
The value of an issuance control system is a reproducible chain from measurement and specification to approval, version, delivery, correction and retention. Evaluate how a product stops wrong or premature issue, not only how quickly it produces a PDF. Use the pilot and FAT/SAT to demonstrate exceptions with real evidence.
If your Thai plant is still mapping interfaces between QMS, LIMS, ERP and customer formats, you can discuss the RFP and acceptance cases with TOMAS TECH. A sample certificate, customer quality agreement and correction case are enough to start defining the right boundary.
Sources
- ISO guidance on documented information.
- ISO and IAF guidance on auditing electronic documented information.
- GS1 Global Traceability Standard.
- GS1 Global Document Type Identifier.
- GS1 Digital Link.
- FDA Part 11 scope and application.
The design and cost example is illustrative. Verify contract-specific retention and regulatory obligations before procurement.
