The key was rejected, or verification returns an authentication error
Likely cause. The API key is missing, mistyped, revoked, or belongs to a different Yashvan account.
What to do. Open IN Compliance Setup and paste the key into the API Key field again — the connection is checked as soon as you enter it. Keys are stored per company, so a key set up in one company is not available in another. If the key was regenerated in the Yashvan portal, the old one stops working immediately and must be replaced here.
Verification fails with an insufficient credits message
Likely cause. The credit balance on the Yashvan account has run out.
What to do. Top up credits at verify.yashvan.com. Credits are consumed only on a successful result, so failed calls do not draw down the balance. The API log in Business Central shows the balance remaining after each call, which is the quickest way to see when it started running low.
Everything is configured but API access is refused
Likely cause. The annual Integration entitlement is missing or has lapsed. A credit balance alone does not authorise API access from an ERP.
What to do. Check the entitlement status in the Yashvan portal and renew it. The entitlement and the credit balance are separate — one can be valid while the other is not.
The scheduled verification job stopped part-way through
Likely cause. The job queue entry ran out of credits mid-run, hit an authentication failure, or was stopped by Business Central after repeated errors.
What to do. Open the job queue entry to see the error and its status. Check the API log for the last successful call — everything before it is verified and does not need re-running. Fix the underlying cause, then restart the entry. If the job consumed more credits than expected, the filter is almost certainly wider than intended.
Credits are being consumed faster than expected
Likely cause. The filter on the scheduled job matches more vendors than intended, or the job runs more often than needed.
What to do. The filter controls both scope and cost — a wide filter across a large vendor master consumes credits in proportion. Narrow it, and reduce the recurrence. The API log records every call with the check performed and the credits debited, so it will show exactly what the job has been doing.
A PAN or GSTIN returns no result
Likely cause. The identifier is not present in the official records, is incorrectly recorded on the vendor card, or the vendor is genuinely not registered.
What to do. Check the identifier on the vendor card first. A vendor with no Udyam registration is a valid answer, not an error — it means the MSME payment rules do not apply to them. Results depend on records maintained by third parties; we do not warrant that they are complete or current.
The MSME due date is not what was expected
Likely cause. The due date comes from the vendor’s standard Business Central payment terms, capped by the MSMED Act limits you configured in setup.
What to do. Check the payment terms on the vendor and the statutory limits in setup. Where the agreed term exceeds the statutory limit, the limit applies; where no term is recorded, the limit applies. The app warns when a due date is breached — it does not block posting.
The Udyam certificate is not attached to the vendor
Likely cause. The certificate is returned by the MSME verifications. If no MSME verification has been run, or the vendor has no Udyam registration, there is nothing to attach.
What to do. Run a MSME verification from the vendor card. The certificate is stored as a standard Document Attachment on the vendor record, inside your own tenant.