Validation Checks

1. Upload criteria (per deal product group)

Payer‑centric deals – upload criteria for standard instruments (face value > 0)

• Mandatory fields present: Instrument Ref, Issue Date, Due Date (for invoices), Seller, Currency, Face Value.

• Seller is an active counterparty on the deal.

• Issue Date is today or in the past.

• Due Date (if provided/required) is on or after Issue Date / today (depending on section).

• Face Value is greater than 0 and within allowed min/max range (1 to 9,999,999,999,999).

• Currency is either the deal limit currency or a “From” currency in the FX template assigned to the deal.

• No duplicate Instrument Reference for the same payer–seller pair across the system, excluding instruments tagged as deleted.

• Deal is active.

• Anchor is active.

• Counterparty is active and active as a deal counterparty.

Seller‑centric deals – upload criteria for standard instruments (face value > 0)

• Mandatory fields present: Instrument Ref, Issue Date, Due Date (for invoices), Payer, Currency, Face Value.

• Payer is an active counterparty on the deal.

• Issue Date is today or in the past.

• Due Date (if provided/required) is on or after Issue Date / today.

• Face Value is greater than 0 and within allowed range.

• Currency is either deal limit currency or included as From currency in FX template assigned to the deal.

• No duplicate Instrument Reference for identical payer–seller pair, excluding deleted instruments.

• Deal, anchor and counterparty are active and the counterparty is active on the deal.

Credit notes – upload criteria (face value < 0)

• Face Value < 0 (negative).

• Same mandatory field and party‑status checks as above but for credit note context.

• Credit note allocation rule exists for the payer–seller pair.

2. Individual instrument creation checks (manual or file‑based)​

When creating an instrument record (before workflow states):

• No field contains only whitespace.

• All required fields present as per Instrument Upload – Field Validation Rules (Instrument Ref, Payer/Seller, Currency, Face Value, Issue Date, Original Maturity Date, etc.).

• Deal exists and is Active.

• Anchor (seller or payer depending on product group) is provided, exists and company status is Active.

• Deal manager funder assigned to deal exists and company status is Active.

• Counterparty (seller or payer depending on product group) is provided, exists and company status is Active.

• Counterparty is Active as a deal counterparty.

• Instrument Reference unique for the payer–seller relationship.

• Currency is supported and is either deal limit currency or From currency in FX template for that deal.

• Face Value must be numeric, digits‑only, between 1 and 9,999,999,999,999.

• Issue Date must be today or in the past, valid format in one of: DD.MM.YYYY, MM-DD-YYYY, DDMMYYYY, YYYY-MM-DD.

• Original Maturity Date must be today or in the future; mandatory for Invoices, optional for other types.

• Original Maturity Date cannot be in the past when mandatory.

3. Bulk file upload validations (CSV/XLS/XLSX)​

Initial file‑level checks:

• File not empty.

• File size ≤ 50 MB.

• File type is CSV, XLS or XLSX (for instruments).

• File contains ≤ 10,000 instruments.

• File has a header row for column mapping.

• All files in the batch share the same header structure.

• Max 5 files per batch.

Column mapping checks:

• Required columns mapped: Counterparties, Instrument Reference, Currency, Face Value, Issue Date, Original Maturity Date (mandatory for invoices), Additional Notes (optional).

• If mapping missing for any mandatory field, mapping cannot be saved / upload blocked.

Per‑row validations after parse use the same rules as “Individual instrument creation checks” above (mandatory fields, date rules, numeric ranges, uniqueness, party statuses, etc.).​

4. Workflow upload validation & submission checks

Upload validation job (“uploadvalidationpending”)

• Runs “Upload Criteria” for the instrument depending on product group.

• If checks fail → status uploadvalidationfailed.

• If checks pass → status readytosubmit.

Submission from readytosubmit

On Instrument Submitted event:

• Re‑run Upload Criteria to ensure nothing changed (deal still active, parties still active, no new duplicate ref, etc.).

• Evaluate “No Financing Allowed” flow (product structure may prohibit financing).

• Depending on eligibility and product settings, instrument transitions to one of:

  • uploadvalidationfailed

  • payerapprovalpendingmakerconfirmation

  • approvednofinancing

  • sellerfinancependingmakerconfirmation

  • payerfinancependingmakerconfirmation

  • funderapprovalpendingmakerconfirmation

  • fundingpending

If any selected instrument fails validation at submission:

• Those instruments go to uploadvalidationfailed.

• Only instruments that pass move forward; user sees error snackbar.​

5. Funding checks (before disbursement)

Executed from fundingpending (manual purchase or scheduled funding):

Limit checks

• Instrument principal/advanced amount in deal currency ≤ programme available limit.

• Same amount ≤ deal available limit.

• Same amount ≤ deal counterparty available sublimit.

FX checks

• Instrument currency equals deal currency, or

• Instrument currency is base and deal currency is target in an active FX rate pair in FX template assigned to deal/counterparty.

Active checks

• Seller company is Active.

• Payer company is Active.

• Counterparty is Active.

• Deal is Active.

• Funder is Active.

Investment day check

• Today must be a valid investment day for funder (e.g. Monday per config).

Tag checks

• Instrument must NOT have tag Not Fundable.

• Instrument must NOT have tag Overdue Not Funded.

• No Financing Allowed / Not Eligible tagging flows are also evaluated and may prevent funding.

If any of the above fail, funding stays in fundingpending or funding fails; errors reported to user.

6. Tagging and daily job validations

Overdue / due tags vs dates

• If Original Maturity Date is set and today > original maturity date, tag Overdue Not Funded is applied (or corresponding overdue tags).

• For funded instruments, daily job evaluates Due Funded, Overdue Within Grace Period Funded, Overdue Outside Grace Period Funded based on repayment schedule and grace rules.

Daily job fix for inconsistent Ready to Submit​

• Every night, find instruments where:

  • Status = readytosubmit, and

  • Tag list includes Overdue Not Funded.

• For such instruments, status updated to uploadvalidationfailed so they no longer appear under Valid tab and cause front‑end validation errors.

“Instrument is Fundable / Eligible / Not Eligible” tagging​

• No Financing Allowed Check Completed may add tags: noteligible, notfundable, noeligiblefundingwindow, remove withinfundingwindow, etc.

• These tag flows depend on:

  • No eligible funding windows.

  • Deal/companies/counterparty inactive.

  • Overdue/No Financing Allowed configuration.

7. Approval‑stage validations (Payer/Seller/Payer Finance/Funder)

These are logical/business validations applied when approving or rejecting:

• At Payer Approval Maker/Checker:

  • Before approval, check deal, anchor, counterparty active; if not, instrument is ineligible and approval fails with error.​

  • Instruments with Not Eligible tag can’t be approved; shown in separate views with explainers.

• At Seller/Payer Finance Maker/Checker:

  • If instrument tagged Not Fundable, Maker/Checker approvals cannot proceed; system throws “Instrument not fundable” exception with reason (inactive deal, inactive party, no eligible funding windows, overdue, etc.).

• At Funder Approval Maker/Checker:

  • Same Not Fundable checks.

  • If instrument Not Fundable, approvals cannot proceed.

• Undo rejection checks:

  • When undoing rejection, tag flows for Due/Overdue Not Funded may be updated (tags removed).

8. Mark as Paid Without Financing checks

When moving to settledwithoutfinancing:

• Instrument status must be one of: approvednofinancing, sellerfinancependingmakerconfirmation, sellerfinancependingcheckerconfirmation, sellerfinancerejected, payerfinancependingmakerconfirmation, payerfinancependingcheckerconfirmation, payerfinancerejected, funderapprovalpendingmakerconfirmation, funderapprovalpendingcheckerconfirmation, funderapprovalrejected, fundingpending.

• Tag Deleted must NOT be present.

• Tag flows: Due Not Funded / Overdue Not Funded removed when marking as paid.

9. Parent Instrument Ref validations​

For Parent Instrument Ref on upload:

• If Parent Instrument Ref is populated:

  • Validate parent instrument exists with:

    • Same currency as child.

    • Same buyer–supplier (payer–seller pair).

    • Instrument reference matches Parent Instrument Ref.

• If no match → error “No parent instrument matches the reference, currency, and buyer–supplier.”

• If Parent Instrument Ref causes circular link to itself or its child → error “Circular reference detected – parent instrument is already linked to this instrument.”

For funding child instrument:

• Parent must be funded and have outstanding balance.

• Child disbursement date must be today and ≥ parent disbursement date.

• If multiple children share same parent with different disbursement dates → funding request rejected with specific error.

• Parent with linked children cannot be deleted.

• Funding of child linked to parent cannot be cancelled.​

10. Instrument field‑level UI validations (front‑end)​

These are enforced in the front‑end but mirror back‑end rules:

• Instrument Reference: mandatory, string length limits, unique per payer–seller, no empty/whitespace, error texts for missing/too long/not unique.

• Payer/Seller: mandatory; drop‑downs limited to deal parties; error if not selected.

• Currency: mandatory; limited to deal currency + FX template currencies; error if empty.

• Face Value: mandatory; numeric only; min/max; error for missing/non‑numeric/out‑of‑range.

• Issue Date: mandatory; cannot be in future.

• Original Maturity Date: mandatory for Invoices; cannot be in past; optional otherwise.

• Supporting documents: type required; file type whitelist; max 50 MB per document; errors for unsupported type/too large.