A funder-ready merchant file is a complete, readable deal record. This guide gives brokers a practical checklist for applications, bank statements, IDs, account verification, existing positions, notes, QA checks, and reusable merchant profiles.
A funder-ready merchant file is more than a folder of PDFs. It is a complete, readable deal record that lets a broker, underwriter, or funding partner understand who the merchant is, what they requested, what the documents prove, what still needs explanation, and why the file is ready for a decision. The public MCA market already points to the same pattern. Broker and ISO submission guides commonly ask for signed applications, recent business bank statements, IDs, voided checks or bank letters, ownership information, and a clear subject or handoff path. The operating lesson is that speed starts before submission: it starts with a file that is complete, named, checked, and easy to review. A clean file does not guarantee approval. It does reduce avoidable delay, duplicate document requests, and confusion between the merchant, broker, ops team, and funder. Start with the story the file needs to tell Before collecting documents, define what the file needs to prove. Most funders are trying to answer a short list of practical questions: Is this the real business? Does the applicant control the account? What cash flow supports the request? Are there existing obligations? Are there red flags that need explanation? Question 1 Who is the merchant? Legal name, DBA, ownership, address, industry, time in business, tax identity, contact information, and signing authority. Question 2 What do they want? Funding amount, use of funds, timing, preferred structure, current balances, payoff needs, and any renewal context. Question 3 What does the cash flow show? Recent bank statements, deposit patterns, revenue concentration, NSFs, negative days, existing withdrawals, and unusual activity. Question 4 What still needs explanation? Mismatched names, missing pages, unexplained transfers, high-risk industry details, existing advances, liens, bankruptcy issues, or seasonal revenue. The core merchant file checklist Requirements vary by funder, product, amount, state, and merchant profile. The point is not to pretend every file needs the same package. The point is to keep a standard checklist so the broker team knows what is complete, what is missing, and what was intentionally waived or deferred. Completed application: legal business name, DBA, owner information, entity type, address, contact information, revenue, funding request, and use of funds. Recent business bank statements: complete, consecutive statements with all pages included, ideally downloaded directly from online banking as PDFs. Government ID: current identification for required owners or authorized signers. Voided check or bank letter: account verification for funding and ACH setup when required. Entity and ownership documents: articles, operating agreement, business license, EIN letter, or other documents where needed. Existing funding positions: current advances, balances, payment frequency, payoff letters, renewal context, or consolidation notes. Processor, receivables, or accounting support: card processor statements, invoices, P&L, tax return, or accounting export when the funder or file size calls for it. Broker notes: short explanation of the merchant story, requested structure, exceptions, and anything the underwriter should not have to infer. The review pass before sending The fastest broker teams do a file QA pass before the funder sees the package. This is not bureaucracy. It is how the team catches avoidable defects while there is still time to fix them. Check What to look for Why it matters Name match Business name, DBA, bank account name, application, and entity documents are consistent or clearly explained. Mismatches create avoidable verification questions. Statement completeness All requested months are present, consecutive, and include every page. Missing pages slow review and can make cash-flow analysis unreliable. Account ownership Voided check, bank letter, or statement evidence supports the account used for funding and repayment. The funder needs confidence the account belongs to the applicant. Existing positions Known advances, daily/weekly payments, liens, or payoffs are documented. Stacking and undisclosed obligations change payment capacity and funder fit. Exception notes NSFs, negative days, seasonal revenue, transfers, or unusual deposits are explained in plain language. Good notes prevent underwriters from guessing. Make the file reusable, not disposable Many brokers treat each submission as a one-time sprint. That creates rework. The better operating model is a reusable merchant profile that gets stronger over time. The first file should preserve the merchant’s application data, documents, notes, funder responses, declines, approvals, stipulations, funded amount, payoff context, and renewal timing. When the merchant comes back, the broker should not need to rebuild the story from old emails. Reusable data Keep the merchant profile current Store business identity, ownership, bank-account context, funding history, and notes as a living record. Reusable documents Know what is fresh and what is stale A bank statement from last quarter may help with history, but it is not a current underwriting document. Track age and purpose. Reusable decision trail Preserve what funders said A decline, counteroffer, approval, or stipulation is valuable context for the next funding conversation. Where Plutus fits Plutus gives broker and funding teams a shared place to assemble and review the merchant file: application information, documents, notes, analysis, lead documents, portal updates, and shareable application context. Instead of treating a file as scattered attachments, Plutus keeps the operating record tied to the merchant and application. That matters for speed, but also for trust. A cleaner file makes it easier for a broker owner to see what happened, for ops to know what is missing, for an underwriter to review context, and for a funder to receive a package that does not depend on one rep’s memory. Operator read A funder-ready file is a trust object. The file tells the funder how organized the broker is before anyone talks about price or commission. Complete documents matter, but so do clear notes, clean naming, exception handling, and a submission trail that shows the team knows what it sent. FAQ What documents are usually needed for an MCA submission? Common requirements include a completed application, recent business bank statements, owner identification, voided check or bank letter, business/entity information, and sometimes tax returns, P&L, processor statements, payoff letters, or other support. Requirements vary by funder and file. What makes a merchant file funder-ready? A funder-ready file is complete enough for review, organized around the merchant and application, checked for obvious defects, and accompanied by notes that explain exceptions or context that the documents alone do not show. Should brokers send files to multiple funders at once? That depends on broker policy, funder relationships, merchant consent, and file fit. Operationally, the important point is to track which funders received which version of the file, what each funder asked for, and what the broker promised back to the merchant. If your team is still building funder-ready files through email threads, Drive folders, and rep-specific notes, Plutus can help turn merchant intake, documents, analysis, and handoffs into one shared workspace. Start with Plutus