Skip to content

Risk Gate

Every other gate looks at the purchase side — margin, price, limits. The risk gate looks at the sales side: who is buying, and how are they paying? It decides whether Trading may order unattended for this buyer, before real money leaves for a supplier.

An order that fails the gate is not lost — it waits in the approval worklist for a person. That is the everyday prepayment workflow: ask for prepayment, release when it arrives.

Why this gate exists

A person sourcing orders by hand glances at the buyer before every order — often without thinking about it. Full automation removes exactly that glance, and that is where the real losses came from: orders on account from customers that never existed.

The pattern is always the same:

  • a throwaway e-mail address, usually a freemail domain
  • a delivery address where a parcel can be collected anonymously — a high-rise, a petrol station
  • the invoice is never paid, while the goods were long since ordered from the supplier and delivered

The risk gate puts the human glance back — as a check before every automatic order.

How the gate decides

The gate is a positive check: an order needs one trust signal, otherwise it waits for a person. The checks run in this order:

  1. A block-list entry matches (handling Block) → the run is held, and the manual release is blocked too, until the entry is removed
  2. The customer is blocked in Business Central or the credit limit would be exceeded (balance + order > limit) → held
  3. A trust signal is present (one is enough) → the order may be sourced
  4. No signal → result Risk Hold: the run waits in the approval worklist

A Block entry beats every trust signal

Block entries come from real fraud cases — this exact value has already cost money once. Even a "paid" payment method does not protect here: PayPal payments and direct debits can be charged back, and whoever created the entry knew that. That is why a Block entry also refuses the manual release.

The trust signals

Signal Condition
Trusted payment method The order's payment method matches a risk rule with handling Trust — e.g. PayPal or prepayment: paid is paid
Marketplace order The Marketplace Order No. field is filled and Trust Marketplace Orders is switched on. Marketplaces collect the money themselves and guarantee the payout — the risk this gate exists for does not arise there
Established customer The customer has at least as many paid invoices as Trusted after Paid Invoices requires (default 2) — and no overdue open invoice

Releasing a held run afterwards re-checks the price as always — the risk decision does not replace the price check.

Order Risk Rules

The Order Risk Rules page is the list the gate learns from — reachable from the Trading Setup. Each row teaches the gate one thing: a payment method it may trust, an e-mail domain that means caution, or an address from a real fraud case that blocks outright.

It is one list across all rule types — deliberately. The person maintaining it is the person handling the fraud cases, and their question is "what do we know about this buyer?", not "which of four separate lists might it be on?".

The rule types

Type What is matched
E-Mail Domain The part of the buyer's e-mail address after the @ — e.g. GMX.DE
E-Mail Address The buyer's full e-mail address
Ship-to Address Substring search over the composed ship-to address — street, post code and city together
Payment Method The payment method code of the order

The handlings

Handling Effect
Trust The match counts as a trust signal — the order may be sourced automatically
Require Approval A ground for suspicion: the run waits for a person, and the hold reason names the match
Block Hard block: held, and the manual release is refused too, until the entry is removed

The Note field records why an entry is on the list — which order or case it came from. The next person to read the list should not have to guess.

Privacy: entries can be personal data

An e-mail address or a delivery address is personal data. Maintain entries only with a documented reason in the note — the concrete case the entry came from — and remove entries whose reason no longer applies.

The setup

The fields live in the Order Risk group of the Trading Setup and in the setup wizard on the "Gates" step:

Field Meaning Default
Check Order Risk The gate's master switch on (for new installations)
Trust Marketplace Orders Whether imported marketplace orders count as paid on
Trusted after Paid Invoices How many paid invoices make a customer trusted, provided nothing is overdue. 0 = history alone never counts 2
Risk Check from Order Value (LCY) De-minimis threshold: orders below this net value are not checked — a small order can be cheaper to lose than to hold. 0 = check every order 0

Behaviour in operation

  • Simulation runs show the gate in advance. A run at level Simulate reports what the gate would have held — the right way to calibrate the rules before real orders wait
  • No duplicates from the job queue. The job queue does not create a second run for a held one — the order waits exactly once in the approval worklist
  • Fail-safe. Whatever the gate cannot judge is held, never waved through: not being able to judge an order is not the same as the order being safe

Where you see the held runs