> For the complete documentation index, see [llms.txt](https://preapproval-guide.imda.gov.sg/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://preapproval-guide.imda.gov.sg/maintaining-your-contract-status/how-to-keep-my-status-as-a-pre-approved-vendor/vendor-guideline-and-compliance.md).
# Vendor Guideline and Compliance
Learn how to stay compliant. The following are commonly observed non-compliance issues.
You are strongly encouraged to read the [Program and Terms and Conditions section](/pre-approval-guide/terms-and-conditions-and-guide.md) to understand how to stay compliant.
## **5 Do’s & Don’ts Every Pre-Approved Vendor Should Know**
**Staying compliant doesn’t need to be complicated.** Keep these five principles in mind when selling, supporting grant applications, delivering projects, marketing your solution and preparing documentation.
> **One simple rule:** what is **approved, sold, documented and delivered should tell the same story.**
Detailed write up on the 5 Do's and Don'ts
*This is a quick reference and is non-exhaustive. Always refer to the official Pre-Approval Guide and Terms & Conditions for the full requirements.*
#### 1. Sell the Approved Package — No Side Deals
**DO:** Compete based on your approved solution, pricing, service quality and customer outcomes.
**DON’T:** Offer cashback, rebates, free modules, additional subscription periods, gifts, credits, barter arrangements or other side benefits to win the deal.
**Remember:** What you sell and deliver should reflect the **approved package**.
***
#### 2. Keep Your Hands Off the SME’s Grant Application
**DO:** Explain the process and direct SMEs to the appropriate official resources or SME Centres for assistance. The official onboarding guide similarly directs vendors to SME Centres or the SME application guide for grant applications. [Preapproval Guide](https://preapproval-guide.imda.gov.sg/pre-approval-guide/stage-4-approval/welcome-to-the-pre-approved-vendor-programme?utm_source=chatgpt.com)
**DON’T:** Access the SME’s Corppass, impersonate the SME, or submit/manage the grant application or claim on their behalf. The compliance guide specifically warns that impersonating SMEs in relation to BGP enquiries can warrant suspension or termination. [Preapproval Guide](https://preapproval-guide.imda.gov.sg/maintaining-your-contract-status/how-to-keep-my-status-as-a-pre-approved-vendor/vendor-guideline-and-compliance?utm_source=chatgpt.com)
***
#### 3. Sell What You Can Actually Deliver
**DO:** Make sure your sales and delivery teams understand exactly what was promised and can deliver the approved solution properly.
**DON’T:** Oversell capabilities, leave commitments to your delivery team to sort out later, or ignore unresolved customer complaints.
**Remember:** A signed deal is not a successful deal if it later becomes an escalated complaint.
***
#### 4. Market the Grant Accurately
**DO:** Follow IMDA's marketing guidelines and use approved programme branding correctly. Reviewing the marketing guidelines and understanding qualifying costs are part of IMDA's onboarding checklist for vendors. [Preapproval Guide](https://preapproval-guide.imda.gov.sg/pre-approval-guide/stage-4-approval/welcome-to-the-pre-approved-vendor-programme?utm_source=chatgpt.com)
**DON’T:** Exaggerate grant support, advertise unsupported funding levels, or present different grants as though they can automatically be combined.
**Remember:** **Sell your solution — don't sell the grant.**
***
#### 5. Keep the Deal and Documents Consistent
**DO:** Ensure the **Package Builder package, quotation, invoice and actual solution delivered** are consistent.
**DON’T:** Change the commercial arrangement outside the approved package or create separate arrangements that change what the SME is effectively receiving.
**Remember:** If the deal changes, **don't fix it through a side arrangement. Follow the proper change process.** IMDA's onboarding checklist specifically directs vendors to the Change Request Process for changes to pre-approved packages.
## **Retrospective Grant Application**
Vendors should understand **when a project may be considered retrospective, distinguish genuine new implementations from renewals or minor enhancements, and ensure no payment or work starts before the grant application is submitted.**
A quick guide to help vendors identify and avoid retrospective grant applications by distinguishing between work already started and genuinely new implementations.
What are some examples of retrospective projects?
**Example 1 — Existing software user**
Client currently uses Accounting Software X and is new to EDGE grant. If my client wishes to apply a new BGP application under Activity “Accounting & Sales Management”, what are the chances of the application being approved?
Potentially eligible:\
✅ Client adopts a different solution as a new implementation such as Software Q, Software A etc, and the new project has not commenced.
❌ Not eligible:\
Client is already using Software X and applies for funding for the same existing implementation.
The important distinction is new implementation vs. existing implementation
**Example 2 — Signed Quotation**
Client has not adopted in solution under Activity “Accounting & Sales Management” but signed my quotation a week before applying in BGP for Software Y, what are the chances of the application being approved?
❌ Not eligible:\
Client has already signed the quotation meaning that project has started. The application will be rejected
The key principle remains the same: the grant is intended to fund new projects, not to subsidise something that is already up and running or ongoing maintenance.
## The Hidden Cost of Side Deals
Freebies, cashback and barter may help win one deal — but can put much more at risk.
## 🚩 See Something Wrong? Report It.
If you suspect non-compliance, **tell us what you observed — you do not need to investigate or prove the case.**
**Look out for:** Cashback or rebates • Freebies or side deals • Barter arrangements • False or misleading documents • Package misrepresentation • Improper grant submissions • Retrospective arrangements
📧 **Report to:** \
🔒 **All information and reports will be kept confidential.**
**Tell us WHO • WHAT • WHEN • Include EVIDENCE where available**
{% hint style="warning" %}
**Q: What are the consequences of breaching the programme's terms and conditions?**
**A:** The consequences will depend on the severity of the breach. Depending on the outcome of our assessment, you may face suspension or termination. If you have any concerns or would like to clarify a specific situation, please do not hesitate to reach out to us.
***
**Q: If I have received a suspension or termination, can I make an appeal?**
**A:** Yes, you may submit an appeal if you have new evidence or information that was not previously considered. Please note that our decisions are made after careful assessment, and appeals will only be reviewed if substantiated by new supporting evidence.
***
**Q: How can I make an appeal for a suspension or termination?**
**A:** To submit an appeal, please prepare the necessary supporting documents and reply directly to the suspension or termination letter you have received. Ensure that your appeal clearly outlines the grounds for your request and is accompanied by any new evidence or information to support your case.
{% endhint %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://preapproval-guide.imda.gov.sg/maintaining-your-contract-status/how-to-keep-my-status-as-a-pre-approved-vendor/vendor-guideline-and-compliance.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
