The warning signs that an MCA software platform is wrong for your operation are usually visible during evaluation. They're just easy to miss, because a demo is built to show the software at its best: a clean deal, a clean workflow, and a salesperson with an answer for everything. The gaps show up after you've signed.
This guide gives you nine red flags that tell you a platform isn't built for how you run, with a clear good answer for each one, so you can catch them before you commit to a contract instead of on your first month live.
A lot of software sold to funders was built for something else first: a general lending platform, a bank loan system, or a CRM with a lending module bolted on. It handles merchant cash advance as a configuration, not as what it was designed for. You feel it in the details: the terminology is off, factor rates get forced into interest-rate fields, and the workflow assumes a monthly amortized loan instead of daily or weekly remittance.
An MCA-native platform speaks your language out of the box. Factor rates, holdback percentages, daily and weekly payment frequencies, syndication, and reverse consolidations are built in, not worked around. Ask the vendor whether the platform was built for MCA specifically, and watch how naturally the demo handles your actual deal mechanics.
Weak support is one of the most common complaints funders have about their software, and it's the thing you feel most when a deal is on the line. When a payment plan breaks mid-funding or a scorecard is scoring wrong, the question that matters is who responds and how fast. If the vendor can't answer that clearly during the sale, it doesn't improve after you sign.
Push on it during evaluation. Ask who you contact when something breaks, how you reach them, and how quickly they respond. A vendor confident in its support gives you a specific answer: named people, real channels, and a response time.
For a deeper set of questions to ask, see our guide on how to evaluate MCA software support before you sign.
Every platform has a roadmap, and a vendor building actively is a good thing. The red flag is when the features you specifically need are the ones described as coming soon. A demo can sell you a feature that doesn't exist yet, and "we're building that now" turns into a wait with no firm date once you've signed.
Separate what's live from what's promised. For every capability that matters to your operation, ask the vendor to show it working in the product today, not on a slide. If it's on the roadmap, get a specific date and get it in writing. A vendor with a mature product can demonstrate the core of what you need live, and is honest about what's still in development rather than blurring the line.
Most MCA platforms price with a base fee plus usage-based charges for things like credit pulls, document parsing, and integrations. That model is normal and fair. The red flag isn't usage-based pricing itself, it's a vendor who won't hand you the full breakdown before you sign. When setup fees, per-user costs, per-transaction charges, and integration fees stay vague during the sale, they turn into surprises on your first invoice.
Ask for the complete pricing structure in writing: the base, what's included, every per-use charge, and every integration fee. A vendor with nothing to hide gives it to you without hesitation and can explain what drives each cost. If getting a clear number feels like pulling teeth, expect the same opacity in billing later.
On a lot of platforms, a deal starts with someone keying it in: copying merchant details from an email, typing figures off bank statements, re-entering the same information into the contract later. That manual entry doesn't go away after onboarding. It's how every deal works for as long as you own the software, and it's a tax on speed and a source of errors on every file.
A platform built for volume pulls deals in and reads the documents for you. Ask how a submission becomes a deal in the system. If the answer is that someone types it in, that's the workload you're signing up for on every deal. If submissions flow in from your intake inbox and the bank data populates on its own, that's the platform doing the work instead of your team.
Demos run the happy path: a standard advance, underwritten and funded without complication. Your operation isn't only the happy path. You have reverse consolidations, non-standard fee structures, specific reporting your capital partners require, and pricing logic that's your own. If the platform can't handle those, you'll keep running them in spreadsheets after you've bought the software.
Bring your edge cases to the demo and make the vendor run them live. The deals that don't fit the standard shape, the reports a bank or investor asks you for, the underwriting rules specific to your shop. If the platform handles them, good. If the answer is "you could export that to a spreadsheet," you've found a gap.
We cover this in depth in our guide on why funders still use spreadsheets after buying software.
If you raise capital from a bank or an investor, they ask for specific reporting: borrowing base reports, static pool by vintage, collection curves, and month-end output their accountants can work with. Many MCA platforms don't produce these, so your finance team exports raw data and rebuilds the report in a spreadsheet every time a capital partner asks. That's ongoing manual work tied to the relationships that fund your business.
Ask the vendor to generate the exact reports your capital partners require, live, from real data. A platform built with institutional reporting produces them natively. One that isn't sends you back to a spreadsheet, which means the software never actually covered one of the most important jobs you have.
Your platform holds your merchants' bank statements, financials, and personal identifiers, plus your own portfolio data. A vendor telling you the system is secure is not the same as an independent auditor confirming it. In a category where sensitive financial data moves constantly and capital partners run diligence on your operation, unverified security is a real exposure.
Ask whether the vendor holds a current SOC 2 Type II report and whether they can share it. That report means an outside auditor examined the security controls over time and confirmed they work. Be careful with phrases like "SOC 2 aligned" or "built to SOC 2 standards," which describe intent rather than a completed audit.
Our guide on what SOC 2 Type II means for your data and capital partners breaks down how to verify the claim.
How a vendor answers your toughest questions during the sale tells you how they'll treat you as a customer. This is the moment they're most motivated to be responsive. If a direct question about a limitation, a missing feature, or a real cost gets a non-answer, a topic change, or a "we'll get to that later," that's the pattern you're signing up for.
Ask the uncomfortable questions on purpose. What can't the platform do? What breaks most often? What isn't built yet? A vendor worth trusting answers directly, including admitting where the product has limits. Deflection when they're trying to win your business is the clearest signal of how support and honesty look once the contract is signed.
None of these red flags are hard to check. They just take asking the questions a demo isn't designed to prompt.
Before you sign an annual contract, make the vendor show you MCA handled natively, name their support, prove features are live, put pricing in writing, show you deals coming in without manual entry, run your edge cases, generate your capital-partner reports live, produce a SOC 2 report, and answer your hardest questions straight.
The vendor built for your operation will clear all nine. The one that isn't will show you exactly where it falls short, which is what you wanted to know before you committed.
Onyx IQ was built for funding operations from the ground up. Book a demo and we'll show you how clients grow deal volume without growing their team.