Home › Functional documentation › File analysis
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. 13Partner institutions and availability
  14. 14Legal review
  15. 15Embedded AI
  16. 16Company workspace, tenders & monitoring
  17. 17CRM, bids & contract management
  18. 18Human resources & delivery capacity
  19. 19Contract guarantees & execution loans
  20. 20Banking file, consent & review
  21. 21Bank decision, issuance & documentary evidence
  22. 22Documentary Collateral & verification limits
  23. 23Access rights, Founders program & notifications
  24. 24Data & integrations: universal exports
  25. 25Connected apps, public API, webhooks & MCP
  26. 26ERP connectors & synchronization
  27. 27Banking API & Collateral
Other documents
Functional documentation

File analysis

Why

A bank receiving a request knows neither the debtor nor the history of the commercial relationship between the assignor and its customer. This process reconstructs verifiable facts — payment history, risk indicators — to reduce this information asymmetry, without ever substituting itself for a credit judgment that only the bank can make.

How, in the application

History reconstructed "as of a date." An invoice is considered settled at a given date only if the sum of payments actually made before that date covers its full amount — never because its current status says so. A payment made after the reference date is ignored: querying the same history twice at the same date always produces the same answer. A delay is treated as an incident only if it strictly exceeds thirty days; a debtor is flagged as slow if its average delay exceeds fifteen days. Every published aggregate carries its calculation formula in plain words, never a plausible-looking value computed on an empty sample.

Grade, score, and payment probability. The scoring engine produces a grade, a numeric score, and a payment probability, as well as an expected delay and risk signals. Each new analysis creates a distinct, versioned row — never an in-place correction of a prior analysis.

Named and transparent. This analysis carries the debtor's and the assignor's real identity. Recipient banks access it according to their subscription rights; the company retains access to its own analysis. The AI-drafted summary is reserved for the bank and saved for later consultation.

Scope of bank-account checks. The risk calculation does not check IBAN consistency and applies no penalty related to that field. A favorable analysis therefore does not validate the bank account.

Safeguards

  • The analysis calculation is wrapped in its own database savepoint: its failure never blocks the submission of the financing request.
  • The history is never rewritten — a new version is added, the old one remains viewable.
  • The company has guaranteed, permanent access to its own analysis: transparency toward the assignor is not a display option, it is structural.