A Nigerian freelancer may be asked for “proof of income,” “proof of funds” or “source of funds,” but those requests do not mean the same thing.
Proof of income usually answers how you earn money and how much income you receive. Proof of funds answers whether you currently have the money you say you have. Source of funds goes one step further and asks where a particular payment or balance came from.
For a freelancer, one document rarely tells the whole story. The cleanest evidence usually forms a chain:
Contract or scope → invoice → payer → payment reference → receiving record
That chain matters because a bank statement can show that money entered your account without explaining why. An invoice can show that you billed a client without proving the client paid it. A contract can explain the commercial relationship without proving that a particular transfer belongs to that contract.
If the reason you are building evidence is that money is already pending or being checked, first identify why freelance payments get held, reviewed or delayed.
There is also no universal freelancer evidence pack accepted by every bank, fintech, payment provider, lender or compliance team. Each reviewer can set its own document requirements. Current Wise guidance, for example, accepts certain tax returns, freelancer-platform earnings statements and qualifying service agreements as possible evidence for freelance or independent-contractor income, while its upload rules also require documents to remain complete and unedited.
This guide is about building clear, traceable payment records. It does not guarantee approval by any bank, payment provider or compliance team, and it is not an immigration-document guide.
Proof of income vs proof of funds vs source of funds: what is the difference?
The easiest way to separate the three is to look at the question each one answers.
Evidence request | What the reviewer is trying to establish | Useful freelancer evidence | What it does not automatically prove |
Proof of income | How do you earn money, and what income do you receive? | Contracts, service agreements, platform earnings statements, tax records where applicable, paid invoices matched with payment records | That you still hold a particular amount today |
Proof of funds | Do you currently have the funds? | Recent bank/account statement, balance statement or another accepted account record | Where the money originally came from |
Source of funds | Where did this particular money come from? | Bank/account record plus contract, invoice, platform payout record, remittance advice or other evidence connecting the payment to its origin | That every other balance or payment has the same source |
This distinction is also used in formal AML practice. FATF guidance describes source of funds in terms of the activity and literal origin that generated the money used in a transaction. The Solicitors Regulation Authority makes the distinction particularly clear: verifying source of funds is not the same as merely proving that the funds exist. These are useful compliance concepts, not a universal document standard for every Nigerian freelancer or financial provider.
A fourth term sometimes appears in compliance requests: source of wealth. That generally concerns how a person's overall wealth was accumulated, rather than the origin of one specific payment. It should not be treated as another name for source of funds.
If the evidence you receive depends on where the client is paying from, the walllet.com guide to receiving payments from US, UK and EU clients explains how those payment routes differ.
Is a bank statement proof of income?
A bank statement can support proof of income, but it does not always prove income by itself.
Suppose your statement contains three monthly credits from the same sender. That may show a recurring payment pattern. It still may not explain whether those credits were freelance fees, salary, a loan, a transfer between your own accounts, reimbursement or something else.
A stronger record connects the credit to its business context:
Statement credit → payment reference → invoice → contract or service agreement
That connection becomes especially useful when transaction descriptions are vague or the entity sending the payment does not have exactly the same name as the client on your invoice.
Provider requirements vary. Wise currently lists full bank statements as acceptable for some income categories but, for freelance work or independent contracting specifically, also lists documents such as a recent validated tax return, a freelancer-platform earnings statement or a qualifying service agreement.
The practical rule is simple: if an organisation specifically asks for a bank statement, give it the type of statement and date range it requests. Do not replace its stated requirements with a homemade “better” evidence pack.
Your payment records become much easier to manage when the route is clear from the start. See how walllet.com helps Nigerian freelancers receive global income, hold dollar-linked value, spend online and cash out through supported routes.
What makes strong proof of freelance income?
Strong proof of freelance income is reconstructable. Someone who did not work on the project should be able to look at your documents and follow what happened without guessing:
Who hired you?
What work or service was agreed?
What amount was due?
When was it invoiced?
Who sent the payment?
What payment reference identifies it?
Where did the money arrive?
If the amount changed between invoice and receipt, why?
That last point matters. A $1,500 invoice followed by a $1,472 account credit is not necessarily inconsistent. Receiving fees, intermediary fees, platform deductions or another documented charge may explain the difference. Keep the record that explains it rather than leaving two unexplained numbers in your file.
If you work with direct clients in different markets, the payment rail can also affect the evidence available to you. The walllet.com guide to receiving payments from US, UK and EU clients explains the differences between common receiving routes and the records each route can produce.
Build the evidence chain from the contract to the receiving record
Consider a synthetic example.
A Nigerian UX freelancer signs a service agreement with Client A Ltd for a research project. The freelancer issues invoice INV-041 for USD 1,250. Client A's finance affiliate, Client A Finance Ltd, sends the payment and includes INV-041 in the payment reference. The freelancer's receiving statement later shows a USD 1,235 credit after a documented transfer fee.
No individual document explains the full transaction.
The service agreement establishes the business relationship. The invoice identifies the work and amount due. The payer record explains who sent the money. The reference connects the transfer to the invoice. The receiving record confirms where and when the payment arrived. The fee record explains why USD 1,235 arrived instead of USD 1,250.
Together, those records tell one coherent story.
The contract or service agreement
Keep the signed agreement when one exists. Useful fields include the parties, effective date, scope or service description, payment terms and agreed compensation.
For recurring work, a master service agreement may cover many invoices. You do not need a new contract for every payment if the existing agreement legitimately covers the work, but each invoice should still be identifiable.
A contract is evidence of an agreement. It is not proof that a payment occurred.
The invoice
A useful invoice normally preserves enough information to connect the work to the payment:
your name or business name;
client name;
invoice number;
invoice date;
service or project description;
amount and currency;
payment terms;
relevant payment details.
An invoice proves that you billed somebody. It does not prove the invoice was paid.
Payer identity
Record the name that actually appears as the sender. This is easy when the client on your contract and the sender on your statement are identical. It becomes more important when payment arrives through a parent company, agency, payroll company, platform or another authorised payer.
Do not rewrite old documents to make the names look identical. Preserve the real records and document the relationship.
Payment reference
A payment reference can be the small piece of data that connects otherwise separate records.
When possible, use a stable identifier such as the invoice number rather than vague descriptions such as “services,” “payment” or “freelancer.”
For example:
INV-041 / UX research
is easier to reconcile than:
PAYMENT
The reference still does not replace the invoice or receiving record. It makes the evidence chain easier to follow.
Receiving record
Keep the official record showing that the payment arrived. Depending on the route, that might be a bank statement, account statement, transaction record or platform payout report. Useful information may include:
account holder name;
payment date;
amount and currency;
sender or payer;
transaction/reference identifier;
receiving account identifier;
payment status.
An ordinary screenshot can be useful for your own troubleshooting, but it is not automatically an acceptable formal statement. Wise, for example, specifically requires bank statements to come from the bank rather than screenshots of online banking for several document categories.
What if the client name and sender name do not match?
A sender/client mismatch does not tell you by itself whether a payment is legitimate. It does create a question your records should be able to answer.
A client may pay through an agency, affiliated company, payroll provider or other payment entity. Current source-of-funds guidance in other regulated contexts similarly treats unexpected third-party funding as something that needs explanation rather than something that should be ignored.
If your invoice says Client A Ltd but your receiving record says Client A Finance Ltd, keep evidence that connects the two. Depending on what exists and what the reviewer accepts, that could include a remittance advice, payment confirmation, client email, contract clause, platform payout record or other genuine documentation.
A short reconciliation note can also make the file easier to understand:
Invoice INV-041 was issued to Client A Ltd. Payment was remitted by Client A Finance Ltd, the entity used by the client to process contractor payments. The payment reference contains INV-041.
Do not manufacture the explanation after the fact. The supporting record should match what actually happened.
What if the payment is being reviewed or delayed?
When a payment is already under review, sending a random pile of screenshots usually makes the case harder to reconstruct.
Build a compact timeline instead:
Invoice issued → client confirmed payment → payment sent → reference generated → payment reached/failed to reach receiving route → support contacted
Keep only the evidence relevant to that payment together.
For an international SWIFT wire, an MT103 or UETR can help identify and trace the transfer. It should not be confused with proof that the beneficiary finally received the money. See the walllet.com guide to tracing a missing international wire with an MT103 or UETR.
How should platform freelancers prove income?
Platform freelancers often have an advantage: the platform may generate structured earnings records that direct-client freelancers have to assemble themselves.
Upwork, for example, currently lets freelancers generate a Certificate of Earnings. It includes gross earnings for the previous one, three, six and twelve months, along with identifying profile information. Upwork also makes clear that it is not the freelancer's employer, so the certificate is proof of platform earnings rather than an employment payslip.
A strong platform-income file can connect:
Platform profile/account → contract or project → platform earnings record → payout record → receiving account
Keep platform fees and withdrawals distinguishable from gross earnings. If a platform says you earned USD 2,000 and your bank received less, the difference should be traceable through fees, withdrawals or conversion records rather than left unexplained.
Creators with platform payouts, sponsorships and direct brand deals may need several evidence types in the same month. The walllet.com guide to payment records and payout routes for Nigerian creators covers that workflow separately.
How do you prove freelance income paid in USDT or USDC?
A blockchain transaction proves that an asset moved between addresses. By itself, it does not explain why someone sent you the payment.
For freelance income paid in a stablecoin, keep both the commercial evidence and the transaction evidence:
Contract or agreement → invoice → agreed token and network → sending/receiving addresses → transaction hash → receiving wallet record
Also record the exact token and network. “USDT payment” is incomplete if the route matters to identifying the transaction.
If the client sent the payment against an invoice, preserve the invoice number or other identifier in your own reconciliation records even when the blockchain transaction itself contains no useful payment description.
The walllet.com stablecoin payment checklist for freelancers covers address verification, network matching, transaction records and other payment-specific checks.
Whether a particular bank, provider or reviewer accepts blockchain records as source-of-funds evidence is a separate question. Follow the recipient's requirements rather than assuming a transaction hash will be sufficient.
How do you prove income from confidential or NDA-covered work?
Confidential work does not erase the need for records, but it can limit what you are allowed to disclose.
Start with the contract. An NDA may restrict the client name, project details, screenshots, product information, financial data or even the existence of the relationship. Redacting the client name does not automatically make disclosure permissible.
If evidence is requested, determine what the requesting organisation needs and what your agreement allows you to share. Where necessary, ask whether it will accept alternatives such as a client verification letter, an earnings statement, a tax document where applicable, or a legitimately redacted agreement.
For an NDA-safe document set, the goal is to disclose enough to substantiate the income without exposing unrelated confidential material. Depending on the request and your contractual obligations, that may mean preserving payment dates, amounts, payer identity or invoice identifiers while removing restricted project details.
Public portfolio proof and financial proof should remain separate. A portfolio is designed to demonstrate experience to prospective clients. A proof-of-income file is designed to establish a financial relationship or transaction.
What can you safely redact from a bank statement?
Redaction is conditional. The first question is not “What can I hide?” It is “Does the recipient accept redacted documents?”
Some providers explicitly require full, unedited statements. Wise's current personal source-of-income instructions, for example, say not to crop, edit or hide information and require the complete statement where a bank statement is requested.
When redaction is permitted, apply a minimum-necessary approach. Nigeria's Data Protection Commission states that personal data should be adequate, relevant and limited to what is necessary for the purpose for which it is being processed.
If the purpose is... | Information that usually needs to remain understandable | Information that may be unnecessary if the recipient permits redaction |
Proving income | Your identity, document issuer, statement period, relevant credits, dates, amounts, currency, payer/reference | Unrelated purchases and unrelated transactions |
Proving funds | Your identity, issuer, statement date, relevant account, balance | Unrelated transaction details if balance alone is sufficient |
Explaining source of funds | Relevant incoming payment, payer, date, amount, currency, reference and supporting commercial record | Transactions unrelated to the payment under review |
Matching an account to you | Your name and enough account-identifying information to establish ownership | Parts of an account number if the recipient does not require the full number |
Never redact a field that the reviewer explicitly requires.
Never change an amount, sender, date, reference or document wording to make the evidence look cleaner. Redaction removes information; it must not change the meaning of the remaining document.
For PDFs, use a real redaction method that removes the underlying text rather than placing a black rectangle over visible content. Keep the untouched original separately.
Which fields should usually remain visible?
When a document is supposed to prove a particular payment or income stream, the reviewer normally needs enough information to identify both the person and the transaction.
For a bank or receiving statement, that can include your name, the issuing institution or provider, statement date or period, relevant payment date, amount, currency, payer and transaction/reference identifier.
For an invoice, that can include the invoice number, date, freelancer or business identity, client identity, description of the billed service, amount and currency.
For a contract or service agreement, the useful fields are usually the parties, effective date, service relationship, payment terms and compensation terms relevant to the income being evidenced.
Different reviewers can require different fields. A document that is perfectly adequate for your accountant may be insufficient for a payment provider's compliance review.
The Nigerian freelancer Payment Evidence Pack
Do not wait for a payment review to start looking for six months of scattered invoices. For each meaningful client or income source, keep a small evidence pack containing:
the signed contract, service agreement, purchase order or other genuine work agreement when one exists;
the invoice or platform billing record;
a record identifying the client;
the name of the entity that actually sent the money;
payment/remittance confirmation when available;
payment reference, transaction ID or equivalent identifier;
the receiving bank/account/platform record;
records of fees, deductions or currency conversion needed to reconcile differences;
a platform earnings statement for platform work where available;
transaction hash, addresses, token and network for stablecoin payments;
a short factual reconciliation note for genuine mismatches;
the original document set plus any separately prepared sharing/redaction version.
A complete evidence pack improves traceability. It does not create a right to approval and cannot override the requirements or risk controls of the organisation reviewing your documents.
Organise records by client and project, not by file type
A folder called Invoices containing 70 unrelated PDFs is useful for bookkeeping but poor for reconstructing one payment.
A client/project structure makes the evidence chain much faster to follow:
Freelance-Evidence/
│
├── 2026/
│ ├── Client-A/
│ │ ├── 01-Agreement/
│ │ │ └── 2026-06-01_service-agreement.pdf
│ │ │
│ │ ├── 02-Invoices/
│ │ │ └── 2026-08-12_INV-041_invoice.pdf
│ │ │
│ │ ├── 03-Payment/
│ │ │ ├── 2026-08-15_INV-041_payment-confirmation.pdf
│ │ │ └── 2026-08-15_INV-041_fee-record.pdf
│ │ │
│ │ ├── 04-Receiving/
│ │ │ └── 2026-08-16_INV-041_receiving-record.pdf
│ │ │
│ │ └── 05-Shared-Evidence/
│ │ └── 2026-08-20_INV-041_receiving-record_REDACTED.pdf
│ │
│ └── Client-B/
│
└── Platform-Income/
└── 2026/
├── Earnings-Statements/
├── Payouts/
└── Receiving-Records/
Use dates in YYYY-MM-DD format so files sort chronologically. Keep invoice numbers and other stable identifiers in filenames whenever they are safe to store.
Keep originals separate from documents you share
Your evidence archive and your sharing folder should not be the same thing.
Keep the original documents unchanged. Create a separate copy only when you need to combine, annotate or legitimately redact records for a particular request.
A simple naming convention prevents confusion:
2026-08-16_INV-041_statement_ORIGINAL.pdf
2026-08-20_INV-041_statement_SHARED-REDACTED.pdf
If you later receive an updated statement, do not overwrite the previous file without a trace. Save the new version with its own date.
This matters because evidence is easier to trust when you can establish which document existed at which point in the payment timeline.
How should payment evidence be shared securely?
Use the organisation's official upload portal when one is provided. A document-request email should not automatically be treated as safe merely because it mentions your account or payment.
Verify the recipient and channel before sharing financial records. Send only the documents needed for that request, subject to the recipient's document rules.
Never include passwords, PINs, one-time passwords, CVVs, recovery codes, private keys or wallet seed phrases in a payment evidence pack. None of those prove freelance income or source of funds.
If you are allowed to send a protected file, confirm first that the recipient accepts password-protected documents; some providers do not. Wise, for example, currently says its source-of-income upload flow does not accept password-protected files.
Keep a basic disclosure record for yourself: what you sent, to whom, through which channel and on what date.
A five-minute evidence check before you send anything
Before submitting a payment evidence pack, check that the documents tell the same story.
Identity: Does your name match across the relevant account and documents?
Client: Is the contracting client identifiable?
Invoice: Can the payment be tied to a specific invoice or billing period?
Payer: Does the actual sender match the expected payer? If not, is the relationship documented?
Amount: If the amount received differs from the invoice amount, can you explain the difference with a real record?
Date: Is the payment timing consistent with the invoice, payout or agreement?
Reference: Is there an invoice number, transaction ID, remittance reference or another stable identifier connecting the records?
Receiving record: Can you show where the money landed?
Version: Are you submitting the correct and current document rather than an old statement or superseded agreement?
Privacy: Have you removed only information the recipient allows you to remove?
The goal is not to make the file look perfect. The goal is to make the transaction understandable without changing what happened.
Ready to make the path from client payment to usable money less fragmented? Explore walllet.com to receive supported global income, hold dollar-linked value, spend online and cash out in Nigeria from one place.
