Common Reasons for Update Rejections
Updated 8/25/20263 min read
Update requests are most often rejected due to missing supporting documents, unclear or vague reasons for the change, or requested details that conflict with information already verified during original registration.
Detailed list of common rejection triggers:
- No supporting document attached for sensitive changes — Bank Details or GST Details updates almost always require formal proof (cancelled cheque, updated certificate) and get rejected without it.
- Vague "Reason for Updation" text that doesn't explain the actual business need — for example, simply writing "change for test" without context gives the reviewer nothing to verify against.
- Mismatched details — for example, a new bank account name that doesn't match the registered company name, raising a red flag for potential fraud.
- Requesting changes outside the scope of the selected category — if you select "Contact Person" but describe a company name change in the reason field, this inconsistency can cause rejection or delay.
- Duplicate or redundant requests — submitting multiple overlapping requests for the same change can cause confusion and rejection of the later ones.
Real example from the system: A request titled "change for test" under Company Details was Rejected — most likely because the reason provided didn't give the reviewer sufficient business justification to approve a change to core legal company data.
How to avoid rejection — a practical checklist:
- Write a specific, business-justified reason (e.g., "Company name updated per new GST certificate dated DD/MM/YYYY" rather than just "name change").
- Attach a clear, legible supporting document for any sensitive field.
- Double-check that the selected "Detailes To Be Updated" tags match what you're actually describing in the reason.
- Ensure new details (like bank account holder name) are consistent with your registered company name.
- If unsure what documentation is required, check with your internal contact before submitting, rather than submitting speculatively.
What to do if your request is rejected:
- Review the Approval Remark, if any, for specific feedback.
- Gather the missing documentation or clarify the reason.
- Submit a fresh Registration Form Update Request with the corrected information.
A comparison of a successful vs. an unsuccessful request: Compare "Request for bank details and pan details update" (with Bank Details + GST Details tags, approved with remark "okay you can update") against "change for test" (Company Details tag, rejected, no remark). The successful example has a specific reason clearly tied to defined categories; the rejected one is vague and untethered to a clear business need — this contrast is the clearest practical lesson for future submissions.
Frequently Asked Questions
Will I be told exactly why my request was rejected?
The reviewer's Approval Remark, when provided, typically explains the reasoning — if it's blank or unclear, follow up directly with your internal contact.
Can I resubmit a rejected request with the same details?
Only if you've corrected the underlying issue — resubmitting identical, unaddressed information will likely result in another rejection.
Does a rejection affect my vendor's Approved status?
No — a rejected update request only means that specific change wasn't approved; your core Approved vendor status remains unaffected.
How many times can I resubmit an update request?
There's generally no hard limit, but each resubmission should meaningfully address the previous rejection reason to avoid repeated delays.
Are minor changes (like a phone number) also at risk of rejection?
Less sensitive changes are typically approved faster with less documentation, but a clear reason is still recommended for smooth processing.
If a request is rejected without a remark, what should I do?
Contact your internal approver or admin directly to understand the reason, since the standard list view may not show enough detail on its own.
Related content
Is this article helpful?
Help us improve our articles.