Home β€Ί Functional documentation β€Ί Financing request
Document menu← Home
Functional documentation
  1. 01Invoicing & OHADA accounting
  2. 02Invoice pipeline
  3. 03Financing request
  4. 04File analysis
  5. 05Offers & structured conditions
  6. 06Competitive position & market ranges
  7. 07Contracts, facility, and financing servicing
  8. 08Institution KYB
  9. 09Institution subscriptions
  10. 10Collateral & borrowing base
  11. 11Third-party custody
  12. 12Alerts & business observability
  13. 13Demonstration network
  14. 14Legal review
  15. 15Embedded AI
Other documents
Functional documentation

Financing request

Why

Once an invoice has been analyzed, the company can ask one or more partner banks to finance it. This process organizes that introduction without ever making Tauraco bear the credit risk or the funds: the platform reviews and routes a file, the decision remains entirely each recipient bank's own.

How, in the application

Eligibility β€” two deliberately separate layers. The platform checks facts about the invoice (not cancelled, not settled, consistent amount, valid due date, available outstanding, no request already open on the same invoice): every refusal reason is collected in a single pass. Each bank's own commercial criteria (ceiling, excluded sectors) remain private to that bank and only serve to filter the possible recipients β€” never to refuse the request itself. Finally, an institution can only receive a request if a financeur eligibility rule explicitly authorizes it for that country and that product, and if its qualification is valid.

Frozen snapshot. At the moment of submission, a snapshot of the invoice, the outstanding balance, the assignor, and the debtor is frozen and signed with a cryptographic fingerprint β€” it also carries the verification level reached and an explicit warning: it is not a guarantee of collection. It answers just two questions: what did the bank receive, and what has changed since β€” with no automatic legal consequence ever drawn from an observed discrepancy.

Recipients. Each recipient bank is added individually, never through implicit broadcast to "all eligible banks"; it is revalidated against the directory at the very moment of submission.

Modes. The institutional RFQ mode is the default: a classic request for quotes, with no relative position ever shown. The competitive mode lets a bank see its own position (best, competitive, non-competitive, sole bidder) without ever seeing the amounts or identities of its competitors. An auction mode exists in the vocabulary, but its engine has not been shipped.

Messages and information requests. Every exchange happens on a thread dedicated to the request-institution pair: one bank's question never concerns another bank. Requesting a document moves the relationship to "information pending"; the reply moves it back to review. Some documents are visible to the whole file, others reserved to a single bank, so as not to hand one institution's review work to its competitors for free.

Tracking a financing request, on the company side.
Tracking a financing request, on the company side.

Safeguards

  • Two distinct refusal reasons exist for an institution with no eligibility rule β€” one for a zone already covered but incomplete, the other for a jurisdiction not handled at all β€” precisely so that a rule can never be guessed by geographic proximity.
  • Removing a recipient after the request has been sent is forbidden, to preserve the trace of who had access to the file.
  • A request draft already reserves the invoice concerned, preventing a second, competing request from being opened on the same invoice.
  • The "financed" status is never inferred automatically: it is recorded only upon the bank's explicit confirmation.