Run an invoice decision
Use a prepared invoice model, check the date cutoff, and inspect the amount and receipt. No generation on your first call.
Should we pay this invoice? How much—and by when? Download a working model and run it. It applies this example policy:
- Unapproved invoices go to review, with no payment authorized.
- Approved invoices paid within ten calendar days of the invoice date, inclusive, receive 2% off.
- Later approved payments use the full amount. Round payable amounts to cents.
For a $25,000 invoice dated October 1, payment on October 11 qualifies: $24,500 payable, with an October 11 discount deadline. Move payment to October 12 and the same policy returns $25,000.
You need an approved preview account, available credits, curl and jq. The example is for testing;
review your own payment terms before using a model in your application.
Get an API key
Sign in to the console, open API keys and create a key. Store it in your server environment. Console and API calls share one credit balance.
export AITYX_API_KEY="aityx_sk_…"
export AITYX="https://api.aityx.ai"Download the prepared model and invoice
These files are the model and invoice used in the supplier-payment recording. The model is the native JSON definition; answer types are inferred from its decisions.
curl --fail -sS https://aityx.ai/docs/examples/invoice-model.json > invoice-model.json
curl --fail -sS https://aityx.ai/docs/examples/invoice-state.json > invoice-state.json
jq '{name, inputs, decisions}' invoice-model.jsonInspect the model format or paste the native JSON into the console’s Decision view.
Run the decision
Send the complete model with the invoice. The rules run directly, without AI.
jq -n --slurpfile model invoice-model.json --slurpfile state invoice-state.json \
'{decision: $model[0], state: $state[0]}' > execution.json
curl --fail-with-body -sS "$AITYX/v1/systemone" \
-H "Authorization: Bearer $AITYX_API_KEY" \
-H "Content-Type: application/json" \
-d @execution.json > matching-run.json
jq '{answers, receipt, usage}' matching-run.jsonThe recorded answers are:
{
"payment_action": "discount",
"payable_amount": 24500,
"discount_by": "2026-10-11"
}This display omits the API answer envelope. Read .answers.payment_action.choice,
.answers.payable_amount.number and .answers.discount_by.date in the full response.
The October 7, 2026 local API recording used 450 input tokens and 200 output tokens, giving a calculated charge of $0.0000189 at the published rate. The local client observed 28 ms including the round trip. Timings and token counts vary. Output is free; the public response reports usage, while settled charges are available in the console.
Test one day past the cutoff
Change only the payment date, leaving approval and the invoice date unchanged.
jq '.state.payment_on = "2026-10-12"' execution.json > late-execution.json
curl --fail-with-body -sS "$AITYX/v1/systemone" \
-H "Authorization: Bearer $AITYX_API_KEY" \
-H "Content-Type: application/json" \
-d @late-execution.json > late-run.json
jq '.answers' late-run.jsonThe policy returns full payment: $25,000, with the same October 11 deadline. Your app decides how to schedule the payment or route an exception; the API returns the policy result.
Keep the reason with the invoice
The receipt is inline. Save it with the original model and input; no lookup request is needed.
jq '.receipt' late-run.json > late-receipt.json
jq '.receipt | {provenance, read, decisions}' late-run.jsonprovenance labels matching facts as state; keep their values in your original request. read is empty on this run because no AI extraction was needed.
decisions records the calculated deadline and the full-payment rule. The service does not retain a
receipt history for retrieval later.
Change the policy when your tests say it is ready
You now have a working decision and evidence for the cutoff. Try increasing the discount to 3% with Compare revised rules. Review the draft, compare the same inputs against both models, and keep the original until you choose to switch. The qualifying invoice should then pay $24,250; late and unapproved cases should not change.
Bring your own case
- Build from a policy or document: create the model outside your live request path.
- Call it from code: complete JavaScript and Python clients.
- Use cases and fit: refunds, service credits and expenses; when a semantic model is a better fit.
- State: read unstructured input and execute in one request, with additional AI latency and usage.

