Home › Functional documentation › Legal review
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

Legal review

Why

Rules used to process a security interest must be reviewed by an authorized lawyer before activation. The legal review module organizes proposals, corrections, validation, and activation of these rules, retaining the identity and authorization of the person responsible for each decision.

How, in the application

A rule moves through a four-position state machine: PROPOSEE_A_VALIDER (proposed, to be validated), then, after validation, VALIDEE_CONSEIL (validated by counsel), and finally, after a second, distinct act, ACTIVEE (activated) — only this last state makes the rule usable in production. The distinction between the last two states is deliberate: counsel can state what the law allows without anyone having yet decided to use it, for example because an engine is not ready or an operational question remains open. A correction position (A_CORRIGER, to be corrected) lets a proposal be sent back upstream without losing it.

Three distinct authorizations govern these acts: reviewing, commenting, and requesting a correction are open to a reviewer; loading a proposal into the review space is open to a rule editor, who carries no validation power. Validating and activating are both reserved to an approver, registered by name with the firm and the source of their authorization. Every correction of an already-proposed rule creates a new version rather than overwriting the previous one — a rule reviewed six months later must be able to show what was submitted and what counsel answered at that time.

The base reference framework covers twenty-two OHADA collateral regimes, supplemented by country-specific national overlays; a cell that is not validated or is explicitly marked unavailable can never be used by default — any operation that encounters it is blocked and explicitly escalated to a human, rather than receiving a default value that would silently produce null collateral.

Safeguards

  • Submitting a proposal and validating it require distinct authorizations: an editor can prepare the review without having the authority to approve the rule.
  • Only rules validated and then activated for the relevant country and regime can be applied to a file.
  • An incorrect default would be worse than a block: a block costs a phone call, null collateral costs the financing's principal.