Raffles Consulting Services
Build an EDGE unique identifier record that links licences, users, deployment evidence, invoices and payment to the approved solution.
An EDGE unique identifier should let a reviewer connect the approved digital solution to the applicant’s actual deployment. The identifier may be a software licence number, user ID or user email address, but it is useful only when the surrounding record proves what was bought, activated and used.
Plan the claim record while the system is configured. Administrators can otherwise rename accounts, remove test users or lose licence details before finance prepares the claim.
Read the deliverable in context
The official EDGE FAQ describes a unique identifier as a project deliverable for single-function digital solutions and integrated enterprise systems. It gives software licence number, user ID and user email address as examples.
The selected activity page and Letter of Offer determine the exact deliverables. For integrated ERP, the official ERP activity page also identifies a unique identifier and photograph of the deployed solution among the project deliverables.
Do not submit an arbitrary username because it fits an example. Choose the identifier that the product and approved activity use to distinguish the applicant’s deployment.
Map the commercial and technical names
Create a one-page identity map. Include the applicant name and UEN, vendor, product, package, tenant or subscription name, licence number, administrator account, approved users, deployment site and subscription period.
Record aliases where the quotation, invoice and portal show different product labels. Explain a legitimate difference instead of forcing every document to use a name that was never part of the transaction.
For a group environment, identify the tenant owner and billing entity. The FAQ states that the supported solution should be used by the applicant entity rather than a subsidiary or related party. A group domain alone does not prove which entity bought and uses the service.
Select a stable identifier
Prefer an identifier that will survive normal staff turnover and that the provider can confirm. A licence or tenant number can be stronger than one employee’s email, while some cloud tools may expose only account or subscription identifiers.
If user email is required, use a genuine authorised user and keep evidence of the person’s role and access. Do not create a dormant account solely for the claim. If the user later leaves, preserve the historical activation record and document the approved transfer of access.
Avoid publishing credentials, passwords, tokens or personal data that is not required. The unique identifier is evidence, not authorisation to reveal secure account information.
Capture deployment evidence
Take screenshots or photographs that show the deployed solution, applicant context and relevant identifier without exposing confidential records. Include the capture date, person responsible and a short explanation of what the image proves.
Where the solution integrates three functions, retain configuration and acceptance evidence for those functions. The EDGE ERP vendor-route guide explains the separate route and scope decision.
Use a representative business record or redacted test case if a screen contains customer or employee data. Never add real sensitive data merely to make the screenshot look convincing.
Reconcile users, licences and costs
Compare the approved quantity and subscription term with the final invoice and active licence record. Explain upgrades, downgrades, free licences, bundled modules and prorated periods.
Build a table with claim line, invoice line, payment reference, identifier, activation date and acceptance evidence. Every claimed item should have a clear path across the table.
The supplier proposal may include migration, integration or professional services. Keep these separate from the licence identifier and confirm which cost components the Letter of Offer supports. A unique identifier does not prove that every invoice line is eligible.
Test the solution before acceptance
Have process owners test the approved functions, access roles, data flow, reports and agreed integrations. Record failures and corrections before final acceptance.
Do not release payment merely to satisfy a claim timetable if the contract allows the company to hold payment for an unresolved defect. Commercial acceptance and grant evidence should tell the same truthful story.
The software filing-controls guide gives a separate example of why system output needs reconciliation. The same discipline applies here: a working screen is not proof that the whole approved workflow is complete.
Preserve changes and administrator handover
Record any change to tenant, product tier, domain, licence quantity, administrator or deployment site. Check the grant terms before a material change and use the official route where notification or approval is needed.
Prepare an administrator handover with secure access procedures, vendor contacts, renewal date and export options. Keep secrets in the approved password system, not in the claim file.
After the claim, retain the identifier and deployment evidence for the required period. A later auditor should be able to understand the historical state even if the live subscription has changed.
Finish with an independent trace
Ask someone outside the implementation team to select one claimed line and trace it through approval, quotation, invoice, payment, identifier, activation and acceptance. Resolve missing links before submission.
Review the wider programme context in the Singapore business support decision guide, the pillar cornerstone. An EDGE unique identifier record is ready when the reviewer can see that the applicant received the approved solution, activated it for real users and paid for the same scope that appears in the claim.
## Test the register before the claim window
Choose three transactions from the accounting records and trace each one through the register to the vendor document, identifier and deployment evidence. Then start from three user identifiers and trace back to the approved solution and invoice. This two-way test exposes gaps that a simple invoice review can miss.
Record exceptions with an owner and due date. Typical exceptions include a licence held under a former employee, an invoice covering both supported and unsupported modules, or an administrator account that does not prove the number of paid users.
Run the same test before staff turnover or a vendor migration. Preserve the old identifier alongside the new one and obtain vendor confirmation where the mapping is not self-evident. The purpose is a continuous evidence chain, not a perfect-looking spreadsheet assembled after the fact.