Order rejected, please resubmit
It is the last week of the month and the customer needs their licences activated by Monday. Your sales support colleague submits the order. An hour later the distributor emails back: rejected, end-user contact email missing. They fix it and resubmit. The next rejection says the address does not match the vendor's record for this customer's agreement. The third time, the domain is wrong because the customer changed their email domain last year.
Each rejection is small. Together they turn a same-day order into a three-day one.
Why end-user details are always a problem
Vendors need to know who the licence is for, and many need it to match an existing customer record on their side. They ask for legal entity name, address, a named contact, sometimes a domain, cloud tenant ID, company registration or an existing agreement number. Each vendor asks for a different set, and some change their requirements over time.
In most reseller businesses, these details are typed onto each order from the PO, from the CRM or from memory. The CRM record was set up for invoicing, not for vendor end-user data, so it often holds a trading name rather than the legal entity, and one contact rather than the licence administrator.
| Field | Common error |
|---|---|
| Legal entity name | Trading name used instead |
| Address | Invoice address, not the registered or site address |
| Contact | Buyer, not the licence administrator |
| Domain or tenant ID | Out of date or mistyped |
| Agreement number | Missing, so a new agreement is created |
What rejected orders cost
Delays are the obvious cost, and they land at the worst times: renewals on their expiry date and orders at quarter end. The less obvious cost is duplicate records at the vendor. An order placed under a slightly different name can create a new customer record or agreement, which causes confusion at renewal, in co-terming and in any later review of what the customer owns.
The end-user data check we build
- Customer data record: each customer gets a vendor-facing record holding legal entity, registered and site addresses, licence administrator contact, domains, tenant IDs and agreement numbers per vendor, separate from invoicing details.
- Verification: legal entity names and registered addresses are checked against Companies House data for UK companies, and domains are checked for basic validity; anything that disagrees is flagged for a person.
- Vendor field rules: the fields each vendor requires on an order are recorded once and kept up to date by your operations team.
- Order fill: when an order is created, end-user fields are filled from the record, not typed, and required fields that are empty stop the order before it is sent.
- Rejection learning: when an order is rejected, the reason is read from the distributor email and the record or the vendor rules are corrected, so the same rejection does not happen twice.
- Customer update prompt: at renewal time, the licence administrator is asked to confirm the key details in a short form, so changes like a new domain are caught early.
Orders after the check is in place
Sales support stops retyping end-user details and stops guessing which entity name the vendor has. Orders go through first time far more often, and when one is rejected, the reason becomes a fix to the record rather than a one-off correction. Renewals stop creating duplicate customer records at the vendor.
Do your orders keep bouncing?
- Distributor orders are rejected for missing or wrong end-user details.
- End-user details are typed on each order.
- Your CRM holds trading names rather than legal entities.
- Customers have ended up with duplicate agreements at a vendor.
- Nobody has a list of what each vendor requires on an order.