9 PSG vendor red flags to avoid in Singapore

The single fastest way to kill a Singapore grant application is to pick the wrong vendor. We're a PSG vendor ourselves, and I've advised on 200+ PSG and 100+ EDG projects — so I've seen this from both sides of the table. Owners do everything else right — clean scoping, strong proposal, proper eligibility — and then the application bounces or the claim gets clawed back because the vendor relationship had a structural problem that should have been caught at quote stage.

Most grant articles focus on the application. This one focuses on the vendor, because the vendor is the part of the grant equation that owners have the most direct control over before any application is filed.

These are the 9 red flags I check for. If any of them are present, the project either needs a different vendor or a substantially restructured engagement before applying.

---

TL;DR — the 9 red flags

1. They pressure you to pay before applying for PSG
2. They claim PSG-approval without showing the current GoBusiness listing
3. They quote in lump sums with no PSG-eligible breakdown
4. They bundle in non-eligible scope (custom dev, integration, premium support)
5. They want the engagement off-LOA structure (informal scope creep)
6. They cannot describe IDP Stage 2 or Stage 3 mapping for an EDG project
7. They have no documented prior PSG / EDG / CTC track record in your sector
8. They have IP ownership terms that conflict with EDG-funded custom builds
9. They cannot produce milestone-based invoices that align to claim milestones

The detail follows.

---

Red Flag 1 — Pressure to pay before applying

Any vendor that asks for a deposit, signed PO, or pre-payment before your PSG application is submitted is either inexperienced with PSG or actively misrepresenting the rules. The rule is unambiguous: any payment before submission disqualifies the entire application.

What you'll hear from a problematic vendor:

• "Lock in the price now with a deposit"
• "Pay 50% upfront to secure the deployment slot"
• "Sign the PO so we can begin scoping"

What a competent PSG vendor will say:

• "Submit your application first. Once approved, we'll invoice you and you'll claim back the subsidy."
• "Here's a quote you can submit with your application. No payment until you tell us the application is approved."

The fix: Walk away from any vendor that pressures you to pay before application submission. The pressure is a red flag for how the rest of the engagement will run.

---

Red Flag 2 — "PSG-approved" claims without GoBusiness verification

Vendors often market themselves as "PSG-approved" or "PSG-eligible" in their sales materials. The list changes over time. A vendor that was on the list in 2024 may not be on it in 2026.

What a competent vendor does proactively:

• Shows you their current GoBusiness vendor listing
• Tells you which solution category they're listed under
• Confirms the listing is current as of the application date

What a problematic vendor does:

• Says "we're PSG-approved" verbally and never shows the listing
• Sends an outdated marketing PDF with old PSG branding
• Promises "PSG will fund it" without specifics on solution code or category

The fix: Ask for the specific GoBusiness PSG listing URL or screenshot. Verify it independently. If they can't or won't produce it, the listing probably isn't current. → See the PSG vendor directory for the catalogue I track.

---

Red Flag 3 — Lump-sum quotes with no PSG-eligible breakdown

PSG claims require line-itemised evidence — what is eligible, what isn't, and how the eligible items map to the listed solution. A vendor that quotes a single lump sum without breakdown is signalling they haven't worked through the claim process before.

A clean PSG vendor quote shows, at minimum:

• The PSG-listed solution code and category
• The PSG-eligible component cost (matches the listed solution scope)
• Any non-eligible components separately (training above standard, customisation, premium add-ons)
• Total project cost vs PSG-eligible portion

The lump-sum problem: at claim time, the officer cannot map the invoice to the listed solution. The claim gets queried, narrowed, or partially rejected.

The fix: Ask for a quote with the PSG breakdown explicit. A vendor that knows PSG will produce it on request. A vendor that resists or returns a generic quote is probably new to PSG.

---

Red Flag 4 — Bundling non-eligible scope into the same invoice

A common pattern: the vendor sells a S$40,000 engagement that includes the PSG-eligible solution AND a S$10,000 custom development add-on AND S$5,000 of training above the PSG-standard package. The owner thinks they'll claim PSG on the whole S$40k. The officer sees the bundle and rejects.

The non-eligible scope items vendors most commonly bundle:

• Custom development work outside the listed solution scope
• Integration work into legacy systems
• Premium support tiers
• Training above the PSG standard package
• Stretch features the vendor wants to deliver

The fix: Two separate engagements, two separate invoices. The PSG-eligible scope sits in one envelope; the non-eligible scope sits in a separate engagement that's either self-funded or wraps into an EDG application for the custom layer.

---

Red Flag 5 — Pushing for off-LOA scope creep

Once the LOA is issued and the project is running, some vendors push to add features, upgrade packages, or deliver "stretch scope" that wasn't in the original application. The work feels valuable in the moment. The problem hits at claim time: the variations weren't pre-approved, so the additional spend isn't claimable, and even the original scope can get queried because the project no longer matches the application.

What this looks like:

• "We can do that integration as a stretch — just pay us directly for it"
• "Let's add this feature mid-project, we'll figure out the paperwork later"
• "It's better to just deliver it and document it after"

What a competent vendor does:

• Flags any proposed scope variation in writing before doing the work
• Asks you to confirm with the grant officer whether the variation is claimable
• Documents the variation formally if approved, or invoices separately if not

The fix: Insist on the formal variation process for any mid-project change. Any vendor that resists this is a future claim problem. See the post-LOA framework: The 30-day post-Letter-of-Offer checklist.

---

Red Flag 6 — No IDP Stage 2/3 mapping for EDG projects

If you're scoping an EDG project, the vendor or consultant needs to be able to describe specifically how the proposed build maps to IDP Stage 2 or Stage 3 of your sector's Industry Digital Plan. A vendor who can't articulate this either hasn't worked on EDG before, or is selling Stage 1 work dressed up as Stage 2/3.

What a competent EDG vendor will say:

• "This addresses Stage 2 functions [X, Y, Z] in the [Sector] IDP — specifically, the integrated data layer and the AI-driven decisioning module"
• "We are explicitly building above what the PSG catalogue covers, because [reason]"

What a problematic vendor will say:

• "Yes, this qualifies for EDG, you'll get 50% funding"
• Vague capability language that doesn't anchor to the actual IDP
• Treating EDG as "basically a bigger PSG"

The fix: Ask the vendor to write the IDP Stage mapping paragraph for your proposal. If they can't, the project either isn't ready for EDG or the vendor isn't ready to deliver an EDG-grade scope. See: IMDA Industry Digital Plan Stages explained.

---

Red Flag 7 — No documented PSG / EDG / CTC track record

Singapore grant work has specific rhythms — application timing, vendor invoicing patterns, evidence requirements, milestone structures. A vendor that hasn't delivered against these schemes before will learn at your expense.

What to ask for:

• Two specific prior projects in your sector or an adjacent one
• The grant they were funded under
• The IDP Stage mapping (for EDG)
• What the claim evidence looked like

What good answers look like:

• Specific named past projects (with permission shared)
• A clear description of the vendor's invoicing structure for those projects
• Honest references about what went smoothly vs what required iteration

What concerning answers look like:

• Generic case study slides with no specifics
• "We've done lots of grant work, can't share details" (everyone says this; ask for one specific anonymised example with the structure)
• Conflating one grant with another in their language

The fix: Verify the track record before signing. The cost of a 30-minute reference check is much smaller than the cost of a grant that bounces because the vendor didn't know how to structure the invoice.

---

Red Flag 8 — IP ownership terms that conflict with EDG-funded custom builds

For EDG-funded custom software or capability builds, the IP arising from the project should sit with the funded entity (your company). Vendors that retain IP in their standard contract, or that require licensing the build back from them, create structural conflicts with EDG's intent.

What to check in the vendor contract:

• Who owns the IP in the custom build?
• Are you receiving a perpetual licence or an outright assignment?
• Can you modify the build without vendor permission?
• Does the vendor retain rights to re-use the build with other clients?

For an EDG-funded build that's supposed to be a defensible capability your company owns, retained-IP vendor contracts are a problem. The grant funded a capability uplift in your business — but if the IP sits with the vendor, the uplift evaporates the moment the vendor relationship ends.

The fix: Negotiate the IP terms before signing the vendor contract. Standard SME-friendly term: full IP ownership to the funded company, with the vendor retaining the right to re-use generic non-proprietary components (which is fine).

---

Red Flag 9 — Vendor cannot invoice in milestones

Grant funding is disbursed at milestones. If the vendor invoices in a single lump sum or in payment terms that don't map to the LOA's milestone schedule, every claim becomes a manual reconciliation exercise — and the officer often can't match the invoice to the milestone evidence.

What a milestone-capable vendor will do:

• Structure their invoicing schedule to match the LOA milestones (or restructure it on request)
• Invoice with a milestone reference matching the grant document
• Provide milestone-specific deliverable evidence alongside the invoice

What an inflexible vendor will say:

• "We invoice 50/50 — half on signing, half on completion"
• "We can't change our standard payment terms"
• "You can use our single invoice for whatever claim you need"

The fix: Negotiate the invoice structure before signing the vendor contract. A 3-milestone vendor invoice for a 3-milestone LOA is the cleanest possible claim trail. A vendor that won't restructure is a vendor that hasn't worked on Singapore grants before.

---

What a clean vendor relationship looks like

Pulling the inverse out of the 9 red flags — the vendor that's worth picking will:

• Tell you to submit the PSG application before any payment
• Show you their current GoBusiness listing on request
• Provide a quote with the PSG-eligible portion broken out
• Separate non-eligible scope into a different engagement
• Flag scope variations in writing for pre-approval
• Articulate the IDP Stage 2/3 mapping for EDG work
• Share specific anonymised prior grant projects in your sector
• Accept IP terms that match the funded entity's interest
• Invoice in milestones that match the LOA structure

If you find a vendor that does all 9, the rest of the grant project becomes substantially easier. Most of the failure modes I see in claim disputes trace back to vendor relationship problems that were visible at quote stage.

---

The pattern across grants

These red flags map slightly differently per grant:

PSG

Red flags 1-4 and 9 are the highest-priority. PSG fails most often on vendor payment timing, off-list vendors, and unstructured invoicing.

EDG

Red flags 4-8 are the highest-priority. EDG fails most often on bundled non-eligible scope, off-LOA scope creep, missing IDP framing, no documented track record, and IP terms.

CTC

The vendor red flags apply but the consultant relationship matters even more — for CTC, the consultant who designs the workforce transformation is effectively the "vendor" for the consultancy line. Red flags 5, 6 (re: process not IDP), and 7 apply directly to the consultant.

MRA

For MRA, the in-market consultant or service provider is the equivalent of the vendor. Red flag 1 (pre-payment), 3 (lump-sum), and 9 (milestone invoicing) apply directly.

---

What to do before any vendor signs

The pre-engagement checklist:

1. Verify their grant track record — two named prior projects, structurally similar to yours
2. Check the current GoBusiness listing (for PSG-eligible work) — at the date of application, not from memory
3. Get a properly structured quote — PSG breakdown, milestone schedule, IP clauses
4. Confirm no pre-payment is required until application approval (for PSG)
5. Walk through the IDP Stage 2/3 mapping (for EDG)
6. Talk to one prior client if possible — even a 15-minute reference call surfaces a lot

If a vendor resists or fails any of these steps, the application risk goes up materially. Better to slow down at quote stage than to discover the problem at claim stage.

---

A note on consultant fees

The consultant who scopes and delivers an EDG project is a different category of "vendor." The consultant fee is itself an eligible cost under EDG (and consultancy is one of the 4 supportable cost lines under CTC).

Two things to verify before signing a consultant:

1. PMC certification (or equivalent SAC certification under TR 43 / SS 680) — this is the official Management Consultant certification recognised across grant frameworks. Not all "AI consultants" hold it.
2. A demonstrated grant track record in your sector with the specific grant you're applying for.

For context: I hold PMC certification (PMC-10960), we're a PSG vendor, and I've advised on 200+ PSG and 100+ EDG projects. I advise — I don't take referral fees from vendors or submit on your behalf. If you want a 15-minute call to talk through whether a specific vendor or consultant is a fit for your project — and what to push back on in their quote — message me. No charge for that conversation.

---

Related reading

• Why your PSG application got rejected — 7 reasons EnterpriseSG won't tell you — the application-side companion piece
• How to scope an EDG proposal that survives the templated rejection — EDG application mechanics
• Reading a Letter of Award — the 5 lines to negotiate — the LOA-side companion piece
• The 30-day post-Letter-of-Offer checklist — what to do once the LOA is signed
• PSG Vendors Directory — the current vendor catalogue I track
• /grants/psg — canonical PSG landing
• /grants/edg — canonical EDG landing

— Nick

Frequently Asked Questions

What is psg vendor red flags?

Psg vendor red flags refers to the approach described in this article. Singapore SMEs apply this practically to reduce cost and increase leverage without adding headcount.

Who should consider psg vendor red flags?

Any Singapore SME owner, manager, or operator looking to streamline their business — especially those running PSG, EDG, or NTUC CTC grant-funded projects.

How long does it take to implement?

Most SMEs see meaningful results within 4-8 weeks of a focused implementation. The bottleneck is usually decision-making speed, not technical complexity.