When a bank or EMI asks what a company does, a clear business activity description is only part of the job.
The next question is often: what supports that description?
That may mean a website, a customer contract, an invoice, a matching payment, a supplier agreement, a licence or financial statements. But these documents answer different questions.
A website may help explain how the company presents its services. A contract shows the commercial relationship and scope. An invoice shows what was billed. A bank statement can confirm that the customer actually paid.
The practical problem is not collecting as much paperwork as possible. It is working out which claims need support, which documents support them, and where the gaps still are.
This guide focuses on how to build that evidence package and how to check whether the documents actually support the same business story.
For the separate question of how to explain the company itself, see How to Describe Your Business Activity for Bank or EMI Onboarding.
What proof of business activity is actually meant to show
“Proof of business activity” is not one standard document.
A bank or EMI may use different wording — proof of nature of business, supporting evidence, business verification — and the documents they accept will vary.
What they are trying to understand is more practical:
- does the company actually appear to do what the application says it does;
- are the customer and supplier relationships credible;
- has trading started;
- does the delivery model make sense;
- do the counterparties, countries and transactions fit the business described.[1–4]
This is why a single document is often not enough.
A contract may show that a client relationship exists. It does not show that the work was completed. An invoice shows that the company billed for something. It does not show that the invoice was paid. A payment confirms money moved, but may say very little about what the payment was actually for.
The useful evidence is usually the combination.
What different documents can actually prove
Not every document carries the same weight, and not every document answers the same question.
A company website can help show how the business presents itself publicly: what it sells, who it serves and how the offer is described. It is useful context, but it does not prove that customers have actually bought anything.
A signed customer contract is stronger evidence of a real commercial relationship. It can show the counterparty, scope and agreed terms, but it still does not tell you whether the work was completed or paid for.
A sales invoice adds another layer. It shows what was billed, to whom and for how much. On its own, though, it does not confirm that the customer paid.
A matching bank transaction closes that particular gap by showing that money actually moved between the parties.
Supplier agreements and supplier invoices are useful when the delivery model depends on contractors, external specialists or other third parties. They can help explain how the company actually produces what it sells.
Financial statements, annual reports, licences and regulatory records may support other parts of the case, depending on the business and the provider’s requirements.[5]
The practical test is simple: what question does this document answer, and what question does it leave open?
Build an evidence chain, not a document pile
A large document pack can still be weak if the documents do not support the same story.
A better way to review the file is to follow the evidence chain:
| Claim | Evidence | What it supports | What is still missing |
|---|---|---|---|
| The company provides cybersecurity consulting | Website | Public description of services | Evidence that clients actually purchased them |
| A client relationship exists | Signed contract | Counterparty and scope | Evidence that work was completed |
| The service was billed | Invoice | Service and amount charged | Evidence that payment was received |
| The client paid | Bank transaction | Payment from the counterparty | Full context of the underlying work |
| External specialists are used | Supplier agreements / invoices | Part of the delivery model | How the wider workflow operates |
If a company says it already serves clients but submits only a website, the business may look plausible, but the trading activity is still largely unsupported.
If the contract, invoice and payment all relate to the same client and the same service, the picture is much clearer.
The value of this framework is that it shows where the evidence stops. That is often where the next onboarding question comes from.
Practical example: when the documents are genuine but the business model still does not add up
One onboarding case involved an IT company that submitted a large set of software-development contracts, invoices and bank statements.
The payments were there. Clients had genuinely paid the company.
The problem appeared when the documents were compared with the company’s actual capacity.
The invoices showed more than 1,000 hours of IT work being billed each month, while the company itself had only one employee: the director. There were also no outgoing payments to contractors or external developers.
The explanation was that the work was being performed by developers employed by another company owned by the same UBO.
That explained the operational reality, but created another problem: there was no contract or other formal arrangement between the two companies.
So the customer side of the story was well documented, but the delivery side was not.
The contracts, invoices and payments were all real, but they still left a basic question unanswered:
who was actually doing the work, and on what basis?
When an established company may need more than contracts and invoices
For many established service companies, the first evidence set is straightforward:
Sometimes that is enough. Sometimes the provider wants another layer.
In practical onboarding work, service businesses may sometimes be asked for an Act of Acceptance or similar confirmation that the work was actually completed.
If the provider has stronger concerns about whether the activity is genuine, the request can become much more specific. In rare cases, that may mean customer correspondence, screenshots of the delivered product, or evidence from the platforms where the work was carried out.
That level of detail is not a standard requirement. It usually appears when the existing evidence leaves a specific question unresolved.
Newly incorporated or pre-trading companies
A new company cannot provide historical evidence that does not exist yet.
In practice, useful documents can include:
- a business plan;
- an investor or company presentation;
- a website;
- draft agreements;
- signed customer or supplier agreements;
- licences or regulatory approvals;
- product or service materials.
Already trading company
Typical available evidence
- signed contracts;
- invoices;
- matching bank transactions;
- completed work evidence;
- supplier / contractor evidence;
- financial history where relevant.
New / pre-trading company
Possible evidence
- business plan;
- company / investor presentation;
- website;
- signed agreements;
- draft agreements as context;
- licences / approvals;
- product or service materials.
Accepted evidence depends on the provider and the specific case.
A signed agreement can support the existence of a real commercial relationship even before invoicing starts.
Draft agreements are different. They can provide context about intended operations, but they should not be presented as proof that trading has already happened.
For some recently incorporated businesses, forward-looking evidence such as a business plan or investor presentation may be accepted where historical trading evidence is not yet available.[6]
Consistency checks before submission
Many onboarding problems appear only when the documents are compared with each other.
A common example is a website describing one set of services while the contract and invoice refer to something materially different.
Another is a mismatch between the wording in the contract and the wording in the invoice.
That does not automatically mean there is a problem with the business, but it creates a question that may need an explanation.
Before submission, check whether:
- the website matches the activity described in the application;
- contracts reflect the products or services being declared;
- invoices fit the contract;
- payments fit the invoice and counterparty;
- contractor or supplier documents support the stated delivery model;
- planned activity is clearly separated from historical activity.
The documents do not need identical wording. They do need to describe the same underlying business.
Common mistakes
The most useful mistakes to watch for are the ones that leave a real business question unanswered:
- the file proves customer payments, but not who actually delivers the work;
- the contract and invoice describe materially different services without explanation;
- planned activity is presented as completed activity;
- the document pack is large, but key claims remain unsupported.
A genuine document can still leave an important part of the business unexplained.
Practical proof-of-business-activity checklist
Before submitting the case, check:
The point is not to maximise the number of documents. It is to make sure the evidence is relevant, coherent and proportionate to the business being described.
For the broader onboarding file, use the corporate bank account opening documents checklist.
A stronger case is not a larger document pack
Proof of business activity is not about submitting every document the company has.
A stronger case is one where the evidence supports the business model described in the application, the documents fit together, and the obvious gaps have been identified before submission.
For an established company, that may mean linking the contract, invoice and payment into one clear chain. For a new company, it may mean showing the evidence that genuinely exists and being explicit about what is still planned.
The exact requirements will vary by bank, EMI and jurisdiction. A well-prepared evidence package can reduce avoidable inconsistencies, but it does not guarantee account approval.
For corporate service providers managing multiple onboarding cases, this is easier when the company profile, supporting evidence and unresolved questions are reviewed together rather than spread across separate emails, spreadsheets and document folders.
OnboardOS is being built as the operating layer for corporate bank and EMI onboarding — helping professional teams structure company information, supporting evidence and onboarding gaps in one workspace.
About the author
Alexander Blinov, Founder, OnboardOS
Alexander’s background includes corporate legal work, KYC/AML and bank and EMI onboarding for international companies. He is building OnboardOS to help professional teams prepare more structured and consistent corporate onboarding cases.
This guide provides general information for corporate onboarding preparation. It is not legal advice and does not represent the requirements of every bank, EMI, payment provider or jurisdiction. Requirements and risk appetites vary by provider and business model.
Sources and further reading
All external sources below were checked on 16 September 2026.
Related resources

How to Describe Your Business Activity for Bank or EMI Onboarding
Read article
Corporate Bank Account Opening Documents: The Complete Checklist
Read article
