Automated Offer Generation: From Credit Policy to Contract
Automated offer generation applies a funder's credit policy to a deal, resolves the exceptions that policy raises, and produces terms that can go straight into a contract. Detection tells an underwriter something is wrong; resolution shows the evidence, records the decision and moves the deal forward.
Resolution, not detection
A parser can say "two existing positions detected". That sentence is where most of the underwriting work begins, not where it ends.
Someone still has to open the debits behind those positions, check them against the funder's maximum-positions rule, decide whether the deal proceeds as an exception, record who approved it, and price an offer the funder will actually honor. When that work happens in a spreadsheet and an email thread, the decision cannot be reconstructed later.
DueDeal runs the sequence as one flow:
- Policy. The funder's rules run against the extracted and reconciled data.
- Exceptions. Anything the policy cannot pass on its own becomes a gate with the evidence attached.
- Offer terms. Terms are derived and labeled funder-stated or calculated.
- Contract. The accepted offer becomes a contract package sent for e-signature.
The gap this fills
A merchant cash advance file arrives as four to six bank statements, an application, and whatever else the broker attached. A document vendor reads it and returns structured data: deposits, average daily balance, NSF count, negative days, month-end balances.
Then an underwriter opens a spreadsheet.
That spreadsheet holds the part that actually differentiates the funder. Which industries are capped at which terms. What multiple of average deposits the funder will advance. Which programs a file can reach given its FICO band and time in business. Which stips are mandatory for a given industry. When a tax return is required. Which cap wins when three of them conflict.
Extraction is widely available. The policy step, and the exception handling that follows it, is where deals actually stall.
What encoding a credit policy actually involves
Every funder says its policy is simple until someone writes it down. It never is. What follows is a representative structure, not any customer's policy.
Layer 1 — hard knockouts. Restricted industry list. Minimum time in business. Minimum monthly deposits. Open bankruptcies. These are cheap to encode and eliminate the largest share of files.
Layer 2 — program qualification. A file lands in a tier from its FICO band, time in business, deposit consistency and industry. Tiers carry different maximum terms, different advance multiples, different fee schedules.
Layer 3 — term and size caps. This is where it gets awkward, and it is the layer that breaks naive rules engines. Real policies stack caps from several directions at once:
- an industry cap, for example transportation or construction limited to nine months
- a size cap, for example any file funded at or below $30,000 limited to eight months
- a program cap, for example the lower tiers limited to eight months while upper tiers reach twelve
- an exposure cap, for example advancing no more than a set percentage of average deposits, with outlier months excluded from that average
A single file can trip three of these. The rule that resolves it is that the most restrictive cap wins, and it has to be evaluated after all of them are computed rather than short-circuited at the first hit. Systems that evaluate rules in sequence and stop at the first match will quietly issue terms the credit committee never approved.
Layer 4 — documentation triggers. Certain industries require a tax return. Inconsistent revenue triggers a further knockdown. Missing statement months hold the file until they arrive.
Layer 5 — the audit trail. Every decision records what the rule saw, where that value came from, and who approved any exception. Without this the output is unusable in a credit committee and indefensible in an audit.
Layers 3 and 5 are where most automation attempts fail. Layer 3 because cap interaction is genuinely fiddly and gets discovered in production. Layer 5 because it is unglamorous and gets deferred.
Exceptions as gates, with evidence and audit
A policy engine that only says "fail" pushes the real work back into email. In DueDeal, an exception is a gate on the deal:
- Evidence is attached. Each detected MCA position links to the debit and credit transactions that support it, with a stacking risk level and refinance links. True revenue shows what was netted out by category: transfers, MCA fundings, owner infusions, reversal credits and returned deposits.
- Policy is enforced. Rules such as the funder's maximum positions apply on the deal.
- Missing documents are flagged. Missing statement months raise a "statements needed" gate. The team sends the request; DueDeal makes sure the gap cannot be missed.
- Verification feeds the gate. A soft credit pull can fire by policy, with the result feeding the approve, adjust or decline decision. DecisionLogic bank verification and Plaid data are checked against the uploaded documents.
- Decisions are claimed and recorded. Gates are claimed and decided from a queue, with admin-only decisions where configured. Every decision writes an audit entry with a frozen snapshot of the evidence and the person who resolved it.
Offer terms you can trace
An offer mixes two kinds of numbers, and confusing them causes funding-call disputes.
- Funder-stated terms come from the funder's approval: the amount, factor and term the funder committed to.
- Calculated terms are derived from those inputs: payback, payment amount, commission and fees.
DueDeal labels each term as funder-stated or calculated. The offer matrix lays out program, term, factor, commission, payback and fees side by side, and deals can be matched to eligible funders and submitted, including to Credibly and Lendr.
The offer is only as good as the numbers under it. Before policy runs, DueDeal audits every bank statement three ways: transactions tie to the statement totals, balances carry correctly from month to month, and grand totals reconcile. Any mismatch is flagged with the exact discrepancy, with no human in the loop, and the full submission is analyzed in 6 minutes.
From offer to contract, funding and renewal
The accepted offer does not get re-typed into another system:
- Contract packages are generated and sent through DocuSign, OpenSign or Adobe Sign.
- ACH collections run through Actum, with Plaid enrollment and auto-debit.
- Payment schedules, returned payments, balance transfers and amendments update the same advance.
- Syndication distributions and ISO commission payouts are calculated from the funded structure.
- Renewal eligibility is tracked by share of term elapsed, and a renewal deal is created from the original in one action.
Keeping underwriting and servicing in one record means the funder can later look at how an exception-approved deal actually paid.
Where the vendors sit
| Layer | Examples | What the layer does |
|---|---|---|
| Statement parsing and scoring | MoneyThumb, priced per statement | Converts and scores bank statements |
| Document analysis | Ocrolus, priced by document type and volume | Extracts financial documents, with human review for hard documents |
| Application analysis and routing | Heron Data | Intake, scrubbing, fraud checks, credit policy decisioning, lender matching and submissions into a CRM |
| Operation | DueDeal | Policy, exceptions with audit trail, labeled offers, contracts, funding, syndication, commissions, servicing and renewals |
For detailed comparisons, see DueDeal vs Heron Data, DueDeal vs Ocrolus and Salesforce MCA software compared.
Where DueDeal is not the answer
Buy something else if:
- The lending is consumer, not commercial. DueDeal handles business lending. Consumer credit carries FCRA, ECOA and adverse action obligations that are a different product.
- The policy is a single statistical scorecard, not a set of rules. If underwriting is one model producing one score, a model-deployment platform is a better fit than a rules engine.
- Policy requires a person to have reviewed every extracted field. DueDeal verifies extraction with arithmetic checks and source pages, not a human review queue.
Run a 20-deal parallel pilot
Keep your CRM and your analysis provider. Give DueDeal 20 deals. DueDeal measures manual touches per deal, submission-to-decision time, decision-to-funding time, exception-resolution time, repeated data entry, missing-document delays, underwriter capacity and funded conversion.
DueDeal starts at $250 a month for the whole workflow. Book a demo to set up a pilot.
Frequently asked questions
What is automated offer generation for MCA funders? Automated offer generation applies a funder's credit policy to extracted deal data, resolves the exceptions the policy raises, and returns terms ready for a contract. DueDeal labels each term as funder-stated or calculated.
How is offer generation different from document parsing? Document parsing converts a bank statement into structured data such as deposits and balances. Offer generation decides what the funder will actually fund. Parsing ends with a dataset; offer generation ends with terms a merchant can sign.
What happens when two credit rules conflict? The most restrictive cap wins. A file that hits an industry cap of nine months, a size cap of eight months and a program cap of twelve months is capped at eight. All caps must be computed before resolution, not evaluated in sequence.
How are underwriting exceptions handled in DueDeal? Each exception becomes a gate with the supporting evidence attached. A team member claims and decides the gate, and the decision is recorded with the resolver and a frozen snapshot of the evidence.
Does automating offers replace underwriters? No. Automation handles the deterministic layer of knockouts, tiering, caps and document triggers. Underwriters keep exceptions, structuring and judgment calls, and spend less time re-keying numbers.
Is automated MCA decisioning auditable? It should be. In DueDeal, every gate decision writes an audit entry with who resolved it and the evidence as it stood, and every transaction keeps its source page.
How long does it take to encode a credit policy? DueDeal setup takes 6 weeks from kickoff to the first live deal, including encoding the credit policy. Encoding the rules is usually faster than agreeing the edge cases the policy document never wrote down.
Sources
Competitor information checked September 2026.
- Heron Data capabilities: herondata.io
- Ocrolus pricing basis and human-in-the-loop review: ocrolus.com/faq
- MoneyThumb per-statement pricing: moneythumb.com/all-products