Embedded invoice financing puts an offer for working capital inside the software where a business issues and tracks invoices. The useful product is not just a button. It is a chain of eligibility checks, receivables data, funding, collections and reconciliation that must still make sense when an invoice is disputed, credited or paid late.

This guide is for B2B platforms designing that chain. It uses the British Business Bank’s explanation of invoice finance, two provider integration documents and the Consumer Financial Protection Bureau’s current small-business lending rule. Provider features are examples, not a universal product specification.

“Invoice financing” is an umbrella label. The underlying transaction may be a loan secured by receivables, a purchase of receivables, factoring or invoice discounting. The name in the product menu does not settle that question.

The British Business Bank describes two common arrangements. With factoring, the provider advances funds and also manages the sales ledger and collections. With invoice discounting, the business normally keeps control of customer collection. Its guide says a factoring provider may advance up to 90% of an invoice. That is a guide figure, not a promise that every borrower, invoice or embedded program will receive 90%.

The distinction matters in the United States too. The CFPB’s interpretation of Regulation B §1002.104 says a factoring transaction, defined as a business-to-business purchase of an enforceable accounts-receivable claim, is not a covered credit transaction for the small-business lending rule. An extension of business credit incident to a factoring arrangement can still be covered and is reported as “Other.” A platform should therefore ask counsel and the funder to classify the actual agreement, not copy a label from a competitor.

For a broader look at the distribution model, see embedded lending and B2B embedded finance.

Map the platform, funder and seller roles

A clear role map prevents the user experience from promising more than the operating model can deliver.

Activity Platform question Funder question
Application Which data can the platform prefill, and with what consent? Who makes the eligibility and credit decision?
Offer Where are amount, advance rate, fees, recourse and repayment shown? Which entity issues the binding terms?
Funding How is the financed invoice identified in the ledger? Who sends funds, and to which verified account?
Collection Does the buyer pay the seller, a controlled account or the factor? Who contacts the buyer and applies receipts?
Servicing What status and balance can the platform display? Who owns adjustments, arrears and complaints?
Closure How are reserves, fees and the final remittance reconciled? What event closes the financing obligation?

Tesouro’s current documentation shows one possible split. Its embedded flow is available to U.S. organizations, the onboarding entry point is supplied through its React SDK, and the API exposes offer and financed-invoice records. The document says only invoices in issued or partially_paid status are eligible and requires a due date at least seven days away. Those are Tesouro’s product rules, not market-wide thresholds.

Stenn documents a different integration pattern: the platform creates a supplier company, buyer information and invoice data, then obtains a short-lived hosted-session link. The user completes the application on Stenn’s hosted form, while webhooks return events to the platform. The example is useful because it makes the handoff explicit. A branded launch point does not mean the platform owns the underwriting or the application record.

Build one receivable record, not three partial copies

The invoice in the accounting system, the invoice submitted for financing and the receivable used for repayment should be traceable to one internal record. At minimum, keep:

  • the platform’s immutable invoice ID and the funder’s invoice ID;
  • seller and buyer IDs, including the verified legal entities;
  • issue, due and payment dates;
  • face value, tax, currency and outstanding amount;
  • credit notes, disputes, partial payments and write-offs;
  • the requested amount, approved amount, advance, reserve, fees and net proceeds;
  • current financing status and the event that produced it;
  • the expected collection account and actual receipt reference.

Tesouro’s API separates financing offers from financed invoices: GET /financing-offers returns onboarding status and available offers, while POST /financing-invoices requests funding and GET /financing-invoices retrieves financing details. That separation is sensible. An offer belongs to the business; a draw belongs to one or more invoices. Combining them in one platform field makes retries and partial approvals hard to explain.

Treat the funder’s identifier as a mapping, not as your primary key. If the platform changes funders later, its invoice history should not be renamed or broken. The same principle applies in a loan servicing migration: external IDs belong in a cross-reference table with their source and effective dates.

Check the invoice before presenting an offer

A financing widget should not turn every unpaid invoice into an eligible asset. Pre-screening can reduce failed applications, but it must mirror the funder’s documented rules and remain clearly provisional.

Useful checks include:

  1. Invoice status. Reject cancelled, draft, fully paid and written-off invoices before they reach the funder.
  2. Amount consistency. Recalculate the outstanding amount after credit notes and partial payments.
  3. Buyer identity. Match the debtor to the verified buyer record, not only to a free-text trading name.
  4. Due date. Apply the funder’s remaining-term rule. Tesouro, for example, requires at least seven days.
  5. Duplicate financing. Record an exclusive financing state so the same receivable cannot be submitted twice or to two funders.
  6. Dispute and performance flags. Do not present an invoice as clean when the buyer disputes delivery or the seller has not completed the underlying service.
  7. Concentration. Send accurate buyer and portfolio exposure data when the funder evaluates limits.

These checks do not replace underwriting. They keep obviously ineligible or inconsistent data out of the application and give the funder a better record to assess.

Design for the exceptions, not only the happy path

Most embedded demos end when the advance lands. Operations begin there.

A buyer may pay the seller’s ordinary bank account even when the financing agreement expects payment elsewhere. A seller may issue a credit note after funding. A buyer may pay several invoices in one transfer. A funded invoice can also become disputed after an initial acceptance. Each case needs a state transition, an owner and a reconciliation rule.

Webhooks should be authenticated, stored before processing and handled idempotently. Keep the provider’s event ID, received time, raw status and the platform action it caused. If the provider retries an event, the platform should not create a second financing record or apply the same payment twice.

Do not let a missing webhook freeze the ledger indefinitely. Run a periodic comparison against the provider’s financed-invoice endpoint and surface exceptions for review. A platform status should say whether it is provider-confirmed or inferred from a pending event.

Collections deserve a separate workflow. If the funder manages the sales ledger, the seller should know who will contact the buyer and how disputes are escalated. If the seller keeps collections, the product needs clear instructions for remitting receipts and reporting adjustments. This is where factoring and invoice discounting create materially different user experiences.

Reconcile cash in four steps

A practical reconciliation follows the money from invoice to final settlement:

  1. Advance: match the funder’s disbursement to the financed invoice and record the net amount received.
  2. Buyer receipt: match the buyer’s payment to the correct invoice or invoice group.
  3. Allocation: split the receipt between principal, contractual fees, any reserve and the seller’s remaining balance.
  4. Closure: confirm the funder’s status, the platform ledger and the seller’s accounts receivable all agree.

Do not hide fees inside a single “funded amount.” Store the gross invoice value, advance, fee components, reserve and net proceeds separately. The British Business Bank’s worked example makes the same arithmetic visible: an 80% facility on £500,000 would advance £400,000, with the remainder less fees and charges released after customers pay. The example explains the structure, not a quote for an embedded program.

When payments cannot be matched automatically, place them in an exception queue with the source reference intact. A manual adjustment should record who made it and why.

What to put in the product and partner review

Before launch, the platform and funder should agree on:

  • the transaction type and the entities shown in terms and disclosures;
  • eligibility rules, decision ownership and how provisional messages are worded;
  • permitted data uses and the evidence of the seller’s authorization;
  • invoice, buyer, offer, financing and event identifiers;
  • duplicate-financing and post-funding adjustment controls;
  • payment instructions, collection ownership and servicing contacts;
  • webhook security, retry behavior and reconciliation frequency;
  • complaints, disputes, fraud escalation and operational incident handling;
  • the export and servicing plan if the partnership ends.

That checklist is deliberately operational. A directory of embedded lending platforms can help identify possible providers, but a provider name does not answer how one program will handle a partial payment or a disputed invoice.