Customer onboarding: cut approval time
How to speed up customer onboarding with validation at entry, prior deduplication and risk-based approval tracks — without losing control over the master record.
Customer onboarding is the process that takes a sales request all the way to an active, sound customer record in the ERP. Approval time drops when you validate data at the point of entry, check for duplicates before opening the record, and run approvals in parallel by risk track instead of in series.
What customer onboarding looks like in practice
Most companies treat onboarding as a sales task: the rep closed the deal, someone creates the record. In practice, it is a master data process. What comes out of it is a customer master record that will govern orders, invoicing, taxation, credit, collections and revenue reporting for years to come.
As long as the record does not exist in the ERP, there is no order, no invoice and no revenue. That is why onboarding is one of the few MDM processes in which slowness shows up directly on the sales side — and where sales pushes back.
The stages of the flow
The typical path of a request, from the sales rep to the customer being released in the ERP, has five stages:
- Sales request. The sales rep opens the record request, usually with the bare minimum at hand: legal name, tax ID and one contact.
- Collection of documents and supplementary data. Tax ID registration certificate, state tax registration, banking details, delivery and billing addresses, intended payment terms.
- Registration and tax validation. Tax ID status, state tax registration and its condition, tax regime, address, contacts and the classification that defines the customer's tax treatment.
- Credit analysis. Definition of limit and terms, with the level of scrutiny varying according to the customer's size and risk.
- Creation in the ERP. Filling in the data across the system views and releasing the record for use.
Where time is lost
Time is rarely lost in the stage everyone blames. It is lost in the gaps between stages.
- Incomplete data at entry. The request is created without the fields the following stages need. Each area discovers what is missing when its turn comes, rather than all at once.
- Back-and-forth with the sales rep. Every missing field becomes an email, a wait and a new queue cycle. A record that passes across the same desk three times consumes three times the queue time, not three times the working time.
- Approvals in series. Tax waits for registration, credit waits for tax, the ERP waits for credit. None of the three necessarily needs to wait for the previous one.
- Rework caused by duplicates. The customer already exists, under a different spelling or in another business unit. The new record is created, the history splits, and someone will later spend time consolidating what should never have been separated.
None of these four issues is solved by asking people to move faster. All of them are solved by redesigning the flow.
How to speed things up without losing control
Speeding up does not mean approving with looser criteria. It means applying the criteria earlier, automatically, and reserving human analysis for what truly requires judgment.
Automatic validation at entry
The highest-leverage point in onboarding is the screen where the request is created. If it queries official sources at the moment of data entry, bad data never enters the queue.
What makes sense to validate at the source: tax ID registration status, state tax registration and its condition, tax regime, normalized address and contacts. We treat this lookup layer as part of the flow, not as an after-the-fact check — see the lookup sources → that feed the validation.
Deduplication before opening the record
The duplicate check has to happen before creation, not after. Search by root tax ID, by similarity of legal name and trade name, by address and by economic group, showing the requester the similar candidates right there on the screen.
When the customer already exists, the flow stops being a creation and becomes a sales organization extension or a data update — a far shorter path. For a base that is already dirty, the work stream is a different one: data cleansing →.
Form with conditional fields
A single form for every type of customer asks the sales rep for fields that do not apply and fails to ask for the ones that do. The result is always the same: blank fields, fields filled in with anything at all, and a guaranteed round trip.
Conditional fields by customer type — legal entity or individual, taxpayer or non-taxpayer, domestic or foreign market, resale or own consumption — reduce the form to what is mandatory for that case and make the mandatory requirements defensible.
Parallel approval tracks by risk
Not every customer deserves the same workflow. A track based on size and risk separates what can move ahead with simple approval from what requires enhanced analysis, and puts in parallel the approvals that do not depend on one another.
Credit and tax are usually independent: they can run at the same time on the same already-validated request. The gain comes from eliminating waiting, not from eliminating control.
How to measure and sustain the gain
Without indicators per stage, all you know is that the record takes too long — not where. The first step is to define an SLA stage by stage and to measure queue time separately from working time.
| Stage | SLA to be defined | Main indicator | Sign that the problem is here |
|---|---|---|---|
| Sales request | Deadline for the sales rep to complete the request | Percentage of requests complete at opening | Many drafts sitting idle and mandatory fields left blank |
| Registration and tax validation | Validation response deadline | Percentage approved on the first attempt | High volume of returns to the sales rep |
| Deduplication | Check on the request screen itself | Volume of duplicates created per period | Same customer with more than one active code |
| Credit analysis | Deadline by risk track | Queue time per track | Low-risk customer stuck in the same queue as a complex one |
| Creation in the ERP | Time between final approval and release | End-to-end time-to-activate | Approved record that takes too long to become usable |
Four indicators sustain the gain over time:
- Time-to-activate: from the opening of the request to the customer being released for invoicing.
- First-attempt approval: share of requests that go through the flow without being returned.
- Rework rate: how many times, on average, the same request comes back for correction.
- Duplicates created: how many new records were created for customers that already existed.
The last point is the one most often forgotten: a customer approved quickly only turns into revenue if the data enters the ERP standardized and sound. Fast onboarding that produces an incomplete record merely shifts the delay to invoicing, to tax determination and to collections. Speed and quality are the same project, not a choice between two.
If you want to see how we structure this flow end to end, start with our material on customer onboarding →.
Frequently asked questions
What is customer onboarding?
It is the process that turns a sales request into an active, trustworthy customer record in the ERP, going through data collection, registration and tax validation, credit analysis and master data creation. It is not an administrative task at the end of a sale: it is the front door of the customer master.
Where is approval time really lost?
In the gaps between stages. Requests that start out incomplete, back-and-forth with the sales rep over every missing field, approvals chained in series and rework to resolve duplicates. The actual working time of each area is usually small compared with the time the request spends sitting in a queue.
Is it possible to speed up onboarding without loosening control?
Yes, because control is now applied up front rather than after the fact. Automatic validation at entry, prior deduplication and risk-based approval tracks maintain — and usually increase — rigor, while eliminating waits that protect nothing.
Why check for duplicates before creating the record?
Because after creation the damage is already done: history split across two codes, fragmented credit limit, distorted invoicing view and a consolidation effort that costs far more than the check would have. Deduplicating on the request screen is the cheapest point in the flow.
Which indicators should be tracked after redesigning the flow?
End-to-end time-to-activate, percentage of records approved on the first attempt, rework rate and volume of duplicates created, all with an SLA defined per stage. Measuring only the total hides the bottleneck; measuring by stage shows where to act.
Who should own the customer onboarding process?
Sales is the requester, and tax and credit are approvers, but governance of the process belongs to the master data area. It is master data that defines validation rules, duplicate criteria, mandatory fields by customer type and the design of the approval workflow.