An order is confirmed, shipped and invoiced in three systems, and only one person knows how to reconcile them. Here is the model behind a tracker, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
An order management tracker is four parts: one order record that survives the whole life of the order, a state model that includes the messy states rather than only the happy path, exception surfacing for the orders that stall, and a reconciliation between what was ordered, shipped and invoiced. The failure is modelling only the good outcome. Real orders get partially shipped, backordered, amended after confirmation and returned, and a tracker that has no state for those pushes them into a spreadsheet somebody keeps privately.
Orders
41
Open orders
6
Stuck over 5 days
88K
Shipped, not invoiced
3
Lines that do not reconcile
Halden Foods, 4471
18,400 · 2 days
Vantor, 4468
6,200 · 1 day
Northrise, 4455
2 of 5 lines · no date for rest
Kestrel, 4449
expected 14 Oct · 11 days stuck
Brightsea, 4441
31,000 · 8 days
Fenwick, 4438
12,400 · 3 days
You run finance operations, order operations or customer operations. Orders pass through several systems and somebody reconciles them by hand. What you want is one view of where every order is and an alert on the ones that have stopped.
What happens to an order between somebody placing it and the money arriving.
Every other system's identifier lives on it, rather than a second record being created per system.
Partially shipped, backordered and amended are columns, not notes, because a state with no home ends up in somebody's spreadsheet.
What changed, who approved it and why, with the previous version kept, because that is where an invoice mismatch is always explained.
Sorted by days stuck rather than date placed, and routed to whoever resolves that kind of problem.
Because a short shipment inside an otherwise correct order nets out at the order level and vanishes.
Shipped and not invoiced is revenue you have earned and not asked for.
An order tracker is not a status column. It is four parts, and the second one decides whether people use it or keep a private spreadsheet.
Customer, lines with quantity and price, dates promised and actual, payment terms, and references into every system the order touches. One record for its whole life, not one per system.
Placed, confirmed, partially shipped, backordered, amended, shipped, invoiced, paid, returned, cancelled. If a real state has no home, it ends up in somebody's notes.
Orders that have not moved, are past their promised date, are partially fulfilled with no plan for the rest, or are shipped and not invoiced. The queue is the exceptions, not the orders.
Ordered against shipped against invoiced, per line. Where they disagree is where revenue quietly leaks, and nobody finds it by reading three separate reports.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
Modelling the mess rather than the happy path.
In this Helix project, build me an order management tracker.
One order record that lives for the whole life of the order: customer,
order reference, order date, promised date, payment terms, currency, and
lines with product, quantity, unit price and line total. Keep the
references into every other system on the same record rather than
creating a second record per system.
Now the state model, and be generous with it. Placed, confirmed,
partially shipped, backordered, amended, shipped, invoiced, paid,
returned, cancelled. Let me edit that list.
Model the messy ones properly. Partial shipment is a state, not a note.
Backordered is a state, with the expected date on it. Amended after
confirmation is a state, with a history of what changed.
If a state that really happens has nowhere to live, somebody keeps a
private spreadsheet for it, and that spreadsheet becomes the real system
within a month.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.Worth knowing. The list of states is the design. Ask the person who currently reconciles orders what they write in the margin, and those are your missing states.
The queue is exceptions, not orders.
Build the working view, and put exceptions in it rather than every order.
Surface: orders that have not changed state for longer than a threshold I
set, orders past their promised date, orders partially shipped with no
expected date for the remainder, orders shipped but not invoiced, and
invoices past due.
Sort by how long the order has been stuck, not by when it was placed.
Those are different, and only the first one tells you where to look.
Each exception routes to whoever can resolve that type, and shows the
order, its history, and the specific thing that is wrong, on one screen.
Give me a per-customer view too, showing every order and its state, which
is what you need open when they ring.Because the invoice not matching the order is always explained by something.
Handle amendments properly.
When an order changes after confirmation, record what changed, who
approved it, when, and why, and keep the previous version. Quantity
changes, price changes, date changes, line additions and removals.
Show the amendment history on the order. When an invoice does not match
the original order, the answer is nearly always in that history, and
without it somebody spends an afternoon in three systems finding out.
Handle returns and credits as their own records linked to the order and
the line, rather than as a negative amendment, so the original order
stays intact and the return is visible as a return.The report where revenue leaks show up.
Add the reconciliation, and do it per line rather than per order.
For each line: quantity ordered, quantity shipped, quantity invoiced, and
the value of each. Flag any line where those three disagree, with the
difference shown.
Group the mismatches by cause where you can: short shipped and not
credited, shipped and never invoiced, invoiced above what shipped,
returned and not credited. Those are different problems with different
owners.
Then report: value shipped and not invoiced, which is revenue sitting
unbilled; average days from placed to shipped and shipped to invoiced,
reported separately because they fail for different reasons; and orders
by state over time, so a growing backordered pile is visible before
somebody complains.The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<NetSuite>. Read orders and invoices, and write back the reconciliation
result. Usually the system of record for the order itself.
<Salesforce>. Read the opportunity the order came from, and write the
order state back so the account team can see it.
<Stripe>. Read payment status so paid is a fact rather than an assumption.
<Okta>. Read the team attribute, so the app can keep customer pricing and
terms to the people who negotiate them.
<Slack>. Tell an owner when an order has stopped moving, with the specific
reason.
<Zendesk>. Show the customer's open tickets on the order, since a stalled
order and a support ticket are usually the same story.
<Snowflake>. Land the full order lifecycle with its timestamps, which is
the only way to see where in the process the time actually goes.
<Coupa>. Where an order is fulfilled by a supplier, read the purchase side
so the two halves reconcile.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. Order data includes customer pricing, so set Access Control before sharing and scope it to the people who need to see terms.
An order touches more systems than almost any other app in this library, which is exactly why it is worth having one record across them.
NetSuite
Read orders and invoices, and write back the reconciliation result. Usually the system of record for the order itself.
Salesforce
Read the opportunity the order came from, and write the order state back so the account team can see it.
Stripe
Read payment status so paid is a fact rather than an assumption.
Okta
Read the team attribute, so the app can keep customer pricing and terms to the people who negotiate them.
Slack
Tell an owner when an order has stopped moving, with the specific reason.
Zendesk
Show the customer's open tickets on the order, since a stalled order and a support ticket are usually the same story.
Snowflake
Land the full order lifecycle with its timestamps, which is the only way to see where in the process the time actually goes.
Coupa
Where an order is fulfilled by a supplier, read the purchase side so the two halves reconcile.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working tracker. It reads and writes across finance and fulfilment systems and its reconciliation feeds revenue reporting, so it needs to be run properly.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
Order records carry customer pricing and terms, which are commercially sensitive. SSO means people sign in with their existing account, and access is scoped to those who need to see them.
App Security
Reading orders, shipments and invoices from three different systems needs real access to each. Granting it to the app rather than pasting keys into it means credentials can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
One record per order that survives its whole life across every system it touches, with a state model covering what actually happens, an exception queue for orders that have stalled, and a reconciliation between ordered, shipped and invoiced.
The messy ones. Partially shipped, backordered, amended after confirmation and returned. Teams model the happy path and then keep the exceptions in a private spreadsheet, which quietly becomes the real system.
By how long an order has been stuck in its current state, not by when it was placed. Those are different numbers, and only the first one points at where the problem is.
Because a short shipment on one line inside an otherwise correct order nets out at the order level and disappears. Per-line comparison of ordered, shipped and invoiced is where unbilled revenue actually shows up.
As a recorded change with the previous version kept, an approver and a reason. When an invoice does not match the original order the explanation is almost always in the amendment history, and without it somebody spends an afternoon across three systems.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build. The judgement call is your state list, and the fastest way to get it right is to ask whoever reconciles orders today what they write in the margin.
Finance
Match invoices to what was approved, route the exceptions, and stop paying late because an email got buried. Prompts to build it, and what it takes to run it.
IT and Operations
Track what you hold by movements rather than a quantity field, reconcile against a physical count, and reorder before you run out. Prompts to build it, and what it takes to run it.
Finance
Show budget owners where they stand before the month closes: committed versus actual, variance by owner, and a forecast they can act on. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.