Quality Management, One More Cut: Supporting the Usage Decision in SAP QM

A quality inspector at a specialty chemicals plant in Ohio starts her Tuesday with 41 open inspection lots in QA32. Fourteen of them are raw material receipts sitting on the dock, blocked in quality inspection stock, with a truck driver waiting on a bill of lading and a production line scheduled to consume that material at 2 PM. She cannot release any of them yet, because for eleven of those fourteen lots, the supplier certificate of analysis has not made it into the system in a usable form.

Two of the COAs are PDFs attached to an email in a shared inbox. One arrived as a scanned fax, tilted about four degrees, with a coffee ring over the assay column. Three came through a supplier portal that her company does not have credentials for anymore, because the person who set up the account left in 2023. The rest are in the folder on the network drive where someone in receiving dropped them, named things like scan_0043.pdf and COA final FINAL v2.pdf.

So she opens each PDF, finds the parameter values, alt-tabs to QE51N or QA32, keys the results in against the inspection characteristics, checks each one against the spec limits in the inspection plan, and eventually gets to QA11 to make the usage decision. Eleven lots. Somewhere between four and six minutes each when nothing goes wrong. Longer when the COA uses a different unit of measure than the plan, or names the characteristic something the plan does not recognize, or reports a range where the plan expects a single value.

This is the part of SAP QM that nobody demos. The usage decision itself takes about eight seconds. Everything that has to be true before that decision is defensible takes most of the morning.

The usage decision is a judgment call wearing a transaction code

In SAP terms, the usage decision is a status change. You pick a UD code from the selected set assigned to the inspection type, the system posts the quantity out of quality inspection stock into unrestricted, blocked, or returns, and the lot closes. Clean. Auditable. Fast.

In practice, the usage decision is the moment where a person accepts personal and organizational responsibility for a batch of material entering the manufacturing stream. In a pharmaceutical or medical device context, that responsibility carries regulatory weight under 21 CFR Part 11 and Annex 11. In food and beverage, it carries HACCP and FSMA weight. In aerospace and automotive, it carries AS9100 and IATF 16949 weight. In every one of those settings, an auditor can pull a lot from three years ago and ask a simple question: what did you know when you released this, and how did you know it?

The answer needs to include the supplier's reported results, the specification the plant was holding the supplier to, the inspection results generated in-house, the batch and vendor history behind the material, and the reasoning that connects all of it to the code that was entered. SAP stores the outcome beautifully. The evidence that produced the outcome is usually scattered across a document management system, an email chain, a lab information system, and the inspector's memory of a phone call.

That gap is the real cost. Not the keystrokes.

Where the time actually goes

Break a single incoming-material usage decision into its parts and the shape of the problem gets clearer.

Somebody has to locate the COA and confirm that it belongs to this delivery. A COA references a supplier batch number, which may or may not match the batch that got created on goods receipt, especially when the receiving clerk transposed two digits or the supplier ships a blended lot with a new internal reference. Matching COA to inspection lot is a small detective exercise that happens dozens of times a day and gets counted as zero minutes of work by everyone who does not do it.

Somebody has to read the values off the document. A COA is a semi-structured document with no industry-wide layout. One supplier reports a table with columns for test, method, specification, and result. Another reports paragraphs. A third reports a table where the specification column contains text like "NMT 0.5%" and "Report only" and "Conforms." Assay might be labeled Assay, Purity, Content, Active Content, or Titre depending on who wrote the template. Water content might be Karl Fischer, KF, Moisture, or LOD, and LOD is not actually the same test, which matters.

Somebody has to compare those values against the right specification. Not the general spec on the material master. The specification that applies to this material, this vendor, this plant, and this inspection type, which lives in the inspection plan with its own validity dates and change history. Plants that maintain vendor-specific tightened limits after a past deviation know exactly how easy it is to check against the wrong number.

Somebody has to look at history. A result of 0.42% against a limit of NMT 0.50% passes. A result of 0.42% against a limit of 0.50% on a material where the last nine lots from this vendor came in between 0.11% and 0.19% is a trend, and a trend is a conversation with the supplier, not a release. The spec limit answers whether the lot is legal. The history answers whether the lot is normal. Both belong in the decision, and only one of them is sitting on the screen in QA11.

And somebody has to write down why. The UD code and the inspector's initials satisfy the system. They do not satisfy the auditor who wants to know why a lot with a borderline result and an open supplier complaint went to unrestricted stock on a Friday afternoon.

Five separate activities, each of which requires pulling information from a different place, and only the last one has a transaction code.

What "supporting the decision" actually means

The goal is not to automate the usage decision. That framing gets rejected by every quality organization that hears it, and rightly so. A named person signs off on material entering production, and that is not a responsibility anyone should want to hand to a model.

The goal is to make sure that when the inspector opens the lot, everything needed to decide is already assembled, already checked, already reconciled, and already flagged where it disagrees. The decision stays human. The preparation stops being human.

That reframing changes what the technology has to do. It does not have to be right about the release. It has to be right about the numbers, honest about its own confidence, and complete in what it surfaces. A system that extracts 34 parameters from a COA, matches 31 of them to plan characteristics with high confidence, and clearly marks the other three as unresolved has done its job. A system that quietly guesses on those three has made the inspector's job harder, because now she cannot trust any of the 34.

Reading the COA properly

Intelligent document processing on certificates of analysis has to solve four problems at once, and skipping any of them produces a demo that works and a deployment that does not.

The first is layout independence. A model trained on one supplier's template collapses when that supplier redesigns the header. Extraction has to work from document structure and semantic understanding rather than fixed coordinates, so that a new supplier onboards without a four-week template build.

The second is characteristic mapping. Pulling "Karl Fischer: 0.32%" off a page is the easy half. Knowing that this plant's inspection plan calls that characteristic WATER_KF with a target of NMT 0.50% and a unit of percent by weight is the half that creates value. That mapping is learned per material and per vendor, and it needs to be reviewable and correctable by the quality team rather than buried in model weights.

The third is unit and basis normalization. A supplier reporting ppm against a plan expecting percent, or reporting on an as-is basis against a plan expecting dry basis, produces a number that looks fine and is wrong by three orders of magnitude. Conversion has to be explicit, logged, and visible on screen next to the converted value.

The fourth is provenance. Every extracted value needs to point back to the exact region of the exact page of the exact source file it came from. When an auditor asks where the 0.32% came from, the answer should be a click, not an archaeology project. This single requirement is what separates a document processing tool that survives a regulatory inspection from one that does not.

Get those four right and the COA stops being a PDF that a human transcribes. It becomes a structured result set that lands against the inspection lot with every value traceable to its source.

Bringing the specification into the same frame

Extracted results are only meaningful against the specification that applies. Pulling that context out of SAP is a well-trodden integration path, and it matters less which technical route you take than that the route is read-consistent and versioned.

The inspection plan for the material, plant, and usage gives you the characteristic list, the target values, the upper and lower specification limits, the units, and the decision-relevant flags such as whether a characteristic is required, whether it is quantitative or qualitative, and what sampling procedure applies. The inspection lot gives you the quantity, the batch, the vendor, the inspection type, and the current status. The material and batch master give you shelf life, restricted-use flags, and batch classification values that sometimes carry quality attributes the plan does not.

Standard SAP interfaces cover all of it. OData services expose inspection lot and characteristic data in a way that suits a modern integration layer. BAPI and RFC calls handle result recording and the usage decision posting itself. Where a customer runs S/4HANA, the released APIs make this straightforward. Where a customer runs ECC with heavy custom Z-fields in the plan, the integration needs to respect those custom fields rather than pretending they do not exist, because in QM the customer-specific fields are usually where the interesting logic lives.

The important design point is that this is a read-heavy integration with a narrow, well-controlled write path. Everything that supports the decision is read from SAP and displayed. The only things written back are recorded results and, on explicit human confirmation, the usage decision itself. That asymmetry keeps the system of record intact and keeps the validation scope small, which is exactly what a quality organization wants to hear when the topic of computer system validation comes up.

The history nobody has time to check

Ask a seasoned inspector what separates a good release decision from a compliant one and the answer will involve memory. She remembers that this vendor's viscosity ran high all last winter. She remembers the deviation on lot 2024-0881 and the corrective action that came out of it. She remembers that the second-source supplier was qualified in a hurry and has been on tightened inspection ever since.

That memory does not scale, does not transfer when she retires, and does not appear in QA11.

Pulling lot history into the decision view is mechanically simple and disproportionately valuable. For the material and vendor combination in front of the inspector, the last twenty lots, their key characteristic values, their usage decisions, any recorded defects, and any linked quality notifications. Rendered as a small trend rather than a table, so that a drift becomes visible in the second it takes to glance at it.

This is where the borderline result gets its context. A single value inside spec but three standard deviations off the vendor's own running mean is not a pass, it is a signal. Statistical process control has known this since Shewhart, and SAP QM supports control charts perfectly well. The reason plants do not act on it at the moment of the usage decision is not ignorance of the method. It is that nobody is going to open a second transaction and run a chart on 41 lots before lunch.

Put the trend on the same screen as the decision and inspectors use it. That is the entire intervention.

What the assembled decision view looks like

Picture the same inspector on a Tuesday six months later.

She opens the worklist. Forty-one lots, sorted so that the fourteen dock receipts with production demand at 2 PM float to the top. For each one, the COA has already been located by matching supplier batch number, delivery note, and material against the inbound documents, extracted, mapped to plan characteristics, unit-converted where required, and written into the inspection lot as recorded results, with the source region of the source PDF one click away from every value.

Eleven lots show green across every characteristic, with all values comfortably inside limits and inside their vendor-specific historical range. She reviews the summary, confirms, and posts the usage decision on all eleven from the worklist. Four minutes, not four hours.

One lot shows an amber flag. Water content came in at 0.44% against a limit of 0.50%, which passes, next to a sparkline showing the previous nine lots between 0.11% and 0.19%. The system does not tell her what to do. It tells her what is unusual. She releases the lot with a deviation note and raises a quality notification to the vendor, which takes ninety seconds because the notification is prefilled with the characteristic, the values, the lot references, and the trend.

One lot shows a red flag on a characteristic the COA did not report at all. The plan requires residual solvent testing. The certificate is silent on it. Instead of that gap being discovered at 4 PM by a production supervisor, it is on screen at 8:15 AM, and the lot goes to the lab for in-house testing while the truck is still in the yard.

One lot shows an unresolved extraction. The scanned fax with the coffee ring produced three values the system could not read with confidence. Those three are marked as requiring manual entry, with the source image displayed alongside the entry field. She keys them in. Ninety seconds, and the correction feeds back so the next fax from that supplier parses better.

The inspector made exactly the same number of usage decisions. She made all of them with more evidence in front of her and none of the transcription work behind her.

The compliance argument is stronger than the efficiency argument

Most automation business cases for QM get built on hours saved. That case is real and easy to calculate. It is also the weaker of the two arguments available.

The stronger one is that assembled evidence produces better decisions and a better record of them. Manual transcription introduces errors at a rate that quality organizations quietly accept because they have no alternative. Studies of manual data entry put keystroke error rates in the range of half a percent to one percent per field, and a COA with 30 characteristics transcribed by hand across a thousand lots a year is a lot of exposure for a process whose entire purpose is catching problems.

Automated extraction with source traceability does not just reduce that error rate. It creates something no manual process produces, which is a complete, timestamped, immutable chain from the supplier's original document through every transformation to the value that appeared on the inspector's screen when she pressed release. During an FDA inspection or a customer audit, that chain is the deliverable. Producing it after the fact from email archives and network drives is the nightmare scenario that every quality manager has lived through at least once.

There is a second compliance benefit that shows up more slowly. When the trend data is visible at the decision point, plants start catching supplier drift months earlier than they used to. The 0.42% that was going to become an out-of-spec lot in September gets raised with the vendor in June. That is the difference between a corrective action and a recall, and it does not appear anywhere on the efficiency spreadsheet.

Where this fits alongside the rest of the QM landscape

Nothing here replaces SAP QM. The inspection plans stay in SAP. The lots stay in SAP. The results stay in SAP. The usage decision posts through standard SAP interfaces and behaves exactly as it always has for downstream batch determination, stock transfers, and reporting.

What sits alongside it is a document intelligence and evidence assembly layer that does the reading, the matching, the normalizing, and the surfacing. It reaches into SAP for the specification and the history, reaches into the document sources for the certificates, reconciles the two, and hands the inspector a decision-ready view. Where a laboratory information management system is in play, in-house analytical results flow into the same view rather than competing with it.

Deployments that work tend to start narrow. One material group, one or two high-volume suppliers, one plant. Get the characteristic mapping right for those, prove the extraction accuracy against a manual control sample, and expand. Deployments that struggle tend to start with a mandate to handle every supplier and every material on day one, which guarantees that the first month is spent on the fifteen suppliers who send handwritten certificates rather than the five who account for eighty percent of the volume.

The other pattern worth copying is treating the mapping layer as a quality-owned asset rather than an IT configuration. The people who know that Titre and Assay are the same characteristic on this material are the people in the lab. Give them the screen where that mapping is maintained and reviewed, and the system stays accurate as suppliers, materials, and plans change.

The eight seconds that matter

The inspector still makes the call. She still owns it, still signs it, still answers for it. That should not change, and the moment a vendor suggests otherwise, the conversation is over in most quality organizations.

What changes is what she is holding when she makes it. Right now, in a lot of plants, she is holding a partially transcribed set of numbers, a spec she checked from memory, no visibility into how this vendor has been trending, and a queue of forty more lots waiting. She is doing skilled judgment work on top of an hour of clerical work, and the clerical work is where the fatigue and the errors come from.

Pull the COA results, the spec limits, and the lot history together before she opens QA11, and those eight seconds become the only part of the process that requires her expertise. Which is what they were always supposed to be.

Artificio builds intelligent document processing and workflow automation for enterprises running SAP. Our SAP Automation Hub covers document-driven processes across QM, MM, FI, SD, and PM, with native integration through OData and BAPI interfaces and full source traceability on every extracted value. To talk through a QM usage decision workflow at your plant, reach us at support@artificio.ai.

Artificio Products Inc., Irvine, California, USA. artificio.ai