MT5 White Label Setup: A Buyer’s Readiness Checklist Before You Pay the Last Invoice
The final invoice is your last point of leverage. Before you pay it, check that what you bought is what you got. This checklist covers what to verify, with evidence, before signing off a white label setup.
Configuration matches the contract
- Trading groups, symbols, leverage and account types match your written plan.
- Branding is applied where promised.
- Hosting, backups and monitoring are live.
Compare line by line with the scope in your agreement.
Integrations work end to end
- CRM account creation and balance operations tested, including failures.
- Payment deposits and withdrawals tested with real small amounts.
- Liquidity bridge passing prices and orders correctly.
Ask for the test evidence, not just a statement that tests passed.
Documents and access are handed over
- Admin credentials and who holds them.
- Configuration documentation.
- Contact list and escalation route.
- Training completed for your staff.
Your own obligations are covered
- Company and banking arrangements in place.
- Licence position confirmed, where needed.
- Client agreements, risk warnings and privacy policy published.
See company formation and licence acquisition.
Sign-off rules
Define acceptance criteria before testing starts and tie the final payment to them. Keep a snag list with dates, and release the last payment when open items are closed. For timing, read our launch timeline guide.
Withhold the last payment until closed
Write the acceptance criteria into the contract and tie the final payment to them. Keep a snag list with dates, and release payment when critical items are closed and non-critical items have agreed dates.
This is a normal commercial practice. Providers who run well-organised projects will not object.
A sign-off table
A sign-off table makes readiness a matter of evidence. Each row needs an owner and a document.
| Area | Contract requirement | Evidence | Signed by |
|---|---|---|---|
| Configuration | Matches the scope sheet | Export or screenshots | |
| Integrations | Tested end to end | Test records | |
| Access | Credentials and roles handed over | Access list | |
| Documents | Manuals and runbooks delivered | Files | |
| Support | Route and hours confirmed | Contact sheet | |
| Your obligations | Payments, policies and training done | Records |
If a row is empty, the area is not ready.
A worked example of withholding the last payment
A buyer’s contract says the final payment is due when the checklist is complete. Two items remain open: a runbook has not been delivered and one integration test failed. The buyer informs the vendor and holds the final payment until both are closed. The vendor delivers within days.
Withholding is not a hostile act. It is the mechanism that keeps the checklist meaningful. Agree it in the contract, in plain terms, so that no one is surprised.
Your own obligations
Buyers also have tasks: provide documents, approve designs, train staff and make payments. A vendor cannot finish if the buyer’s tasks are late. Track yours with the same rigour as theirs, and record dates. If a delay is yours, say so early.
Sign-off rules
- Define who signs for each area.
- Define what counts as passing.
- Record exceptions with dates and owners.
- Do not sign on promises; sign on evidence.
See our setup walkthrough for the earlier stages.
Why buyers should insist on a handover pack
A handover pack contains the documents you need to run the system: configuration records, access lists, runbooks, contact sheets and test results. Ask for a list of the pack’s contents before signing, and make delivery a condition of final payment.
A handover pack protects you if staff change at the vendor or on your side, and it speeds up onboarding of your own team.
A realistic acceptance test
Agree an acceptance test with the vendor: a set of scenarios, the expected results and who judges them. Run it together and record the outcome. If a scenario fails, agree a fix and rerun. The test turns "ready" from an opinion into a result.
After sign-off
Sign-off is not the end of the relationship. Agree how defects found after launch will be handled, for how long they are covered and how changes will be priced. A clear post-launch arrangement avoids disputes.
Making the checklist part of the contract
To give the checklist force, refer to it in the contract. State that the vendor will deliver the items listed, that acceptance will be based on evidence and that final payment is due when the checklist is signed. Attach the checklist as a schedule.
Vendors who are confident in their work are usually willing to accept this. If a vendor objects, ask which items it cannot commit to and why. The answer may reveal gaps in what it plans to deliver.
Keeping evidence in order
Store the evidence for each item in a shared folder with clear names and dates: configuration exports, test records, signed approvals and handover documents. Assign someone to keep the folder tidy. When questions arise months later, you will find the answer in minutes.
Good records are an asset in disputes, in audits and when you bring in new staff or a new provider.
A final conversation with the vendor
On the day before launch, hold a short call with the vendor to confirm: who is on call, how to reach them, what changes are frozen and what will happen if something fails. Write down the answers and share them with your team.
A short conversation like this prevents confusion at the moment when it matters most, and it signals to the vendor that you are organised and expect the same of them.
Frequently asked questions
What belongs in a readiness checklist?
Configuration, integrations, access, documents, support and your own obligations, each with evidence.
Should I withhold payment until the checklist is complete?
Many buyers agree a final payment on completion. Put it in the contract.
Who signs the checklist?
The owner of each area on both sides.
What if the vendor disagrees?
Refer to the scope sheet and test records. Escalate if needed.