Most conversations about AI in procurement start with the technology. A better starting point is the work: which parts of supplier onboarding are slow, repetitive and low in judgement, and which parts carry risk that someone must own.
A simple test
For each step in your onboarding process, ask two questions.
- Is the step mainly reading, comparing or chasing? If yes, it is a strong candidate for automation.
- Would you need to explain the outcome to an auditor, a regulator or a court? If yes, a person should make or confirm the decision, even if software prepares it.
Most steps fall clearly into one group or the other. The interesting ones are in between.
Good candidates for automation
Reading documents. Extracting the registration number, expiry date and issuer from a certificate, or the account details from a bank letter, is slow for people and reliable enough for software when the output is checked.
Comparing values. Does the name on the bank letter match the registered entity? Does the tax number match the format for that country? Is the certificate current? These comparisons are rule-based and repetitive.
Checking registries. Looking up an entity in an official registry is mechanical. Software can do it consistently and record the result.
Routing and reminding. Sending a submission to the right reviewer based on category or risk, and reminding suppliers about missing documents, is coordination work that rarely needs judgement.
Preparing product data. Mapping supplier attributes to your taxonomy, flagging missing mandatory fields and proposing corrections is a large share of product onboarding effort.
Steps that need a person
Approving a supplier. Approval commits the organisation. It should be made by someone with the authority to make it.
Resolving exceptions. When the name on the bank letter is slightly different from the registered name, someone needs to decide whether that is a trading name, a typo or a warning sign.
Weighing risk. Deciding whether a supplier with a minor issue is acceptable for a particular category depends on context that software does not have.
Designing the boundary
The most useful pattern is “software proposes, people decide”. Automation does the reading, comparing and checking, presents its findings with the evidence behind them, and marks what it is confident about and what it is not. A reviewer then works through exceptions rather than through every field.
Three design choices make this pattern trustworthy:
- Proposals are labelled. It should always be clear what was suggested by software and what was entered by a supplier or a reviewer.
- Thresholds are set by the organisation. Administrators decide how confident the system must be before a suggestion is shown, and which checks must always be reviewed.
- Everything is recorded. The history shows what the software found, what the reviewer decided and why.
How Skuvet applies this
Skuvet uses automation to read submitted documents, run checks against enabled registries, compare values and propose corrections to product data. Administrators control which assistance is enabled and with what settings. Approval decisions remain with people, and the audit history records both the automated findings and the human decision.
