A CFO system for business decisions
Before you commit to a purchase, a lease or a hire, Qelly is being built to check the decision against your cash, your obligations and the payments you are still waiting for. Its decision brief shows the plans that keep your cash reserve, what each costs, the assumptions behind them and the facts that could change the answer. Today it runs on synthetic examples, like the one below.
For owners of small and medium businesses and the people who manage their finances. We are seeking first pilots, starting with private medical practices.
The example
A synthetic food distributor asks whether it can place a US$150,000 equipment order. Change when its largest customer pays, or require any option, and every plan is recounted in your browser. The same check applies to a practice weighing a new device; in a pilot, it would be computed from that practice's own inputs.
The question
The uncertain fact
A US$64,000 receipt from your largest customer, invoiced for week 2.
Their latest message “We'll release the payment right after our quarter close.”
Cash in each week
If the payment date moves
| Customer pays | Plans that place the order | Lowest cost |
|---|---|---|
| Week 2, as invoiced | 85 plans | US$2,850 |
| One week late | 16 plans | US$4,935 |
| Two weeks late | none | — |
The next question Will the US$64,000 arrive in week 2? If it might slip a week, the cheapest plan that meets the reserve either way costs US$4,935. Confirming the date could save up to US$2,085 under these assumptions. That is a possible saving, not an expected value: the example assigns no probabilities.
Every plan, checked
85 of 5,184 possible plans place the order and keep cash at or above the reserve every week. 1,333 meet the reserve if deferring the order is also allowed.
Each row is one decision. A bar shows the share of the counted plans that use that option. These are shares of modeled combinations, not probabilities; splitting one choice into several equivalent options would change them. Select an option to require it.
Opening cash is US$150,000 and the reserve is US$50,000. Committed weekly flows net confirmed collections against payroll, rent, taxes and loan service. The US$64,000 receipt sits in week 2 unless you move it. Late fees, the staging fee, the premium for ordering later and credit interest are paid in cash in the week they apply, so they lower closing cash; the early-payment discount reduces that week's payment. The one cost that is not a cash payment is an estimate of the margin lost by deferring the order beyond week six.
| Week 1 | Week 2 | Week 3 | Week 4 | Week 5 | Week 6 |
|---|---|---|---|---|---|
| +10,000 | +20,000 | +70,000 | +45,000 | +10,000 | +70,000 |
| Week 1 | Week 2 | Week 3 | Week 4 | Week 5 | Week 6 |
|---|---|---|---|---|---|
| 52,000 | 50,790 | 50,270 | 54,550 | 64,550 | 53,150 |
Method. The six weeks form a chain. Between weeks Qelly carries the closing cash and which decisions are still open. Multiplying the weekly constraint tables once with ordinary arithmetic counts every plan that never dips below the reserve; doing it again in min-plus arithmetic returns the cheapest one. An independent replay then re-adds the chosen plan week by week. This is dynamic programming written as a tensor-network contraction, so the same instance also exports to MILP, QUBO, Ising and CQM formats for other solvers.
What each check establishes. Counting every combination makes the count and the lowest cost exact for the options and inputs listed here. The replay confirms the reported plan's cost and cash path. Neither shows that the inputs describe a real business.
A transparent synthetic example, not a connected client account or a live product feature. Exact means every combination of the listed options was checked against these inputs; it does not make the inputs right. Scenarios carry no probabilities, and plan shares are not forecasts. Returns on the equipment are not modeled, and costs beyond week six are outside this example.
The workflow we're building
The example above starts from inputs we typed in. The connected workflow is planned: it would start from your own records and end with a decision brief you can check. Parts of it exist as synthetic prototypes.
Planned. Bank balances, scheduled payments, invoices and messages would become facts you can check, each with its source, its date and whether a person has confirmed it. In the prototype, language models read synthetic text into bounded judgments; they never supply the figures.
For the choices you put on the table, such as payment timing, staging and financing, Qelly counts the plans that keep cash at or above your reserve and finds the one with the lowest stated cost.
It reruns the check under each open fact, such as a collection date, and shows how much the answer changes, so you know what to confirm before you commit.
Planned. Each brief would carry its inputs, an independent replay of the arithmetic and a fingerprint. The arithmetic is reproducible; the input facts still need confirming. You make the call.
First pilots
We are seeking first pilots with private medical practices. A pilot would need no lender or other partner: just the practice and one decision it faces again and again.
Who is building Qelly
Luis is the sole author of the quantum-annealing preprints linked below, which are not peer-reviewed. He built Qelly's decision engine, its benchmark and its evidence-intake prototype.
Qelly is a product of Great Bear AI LLC, a Florida company. luis@qelly.ai
What we're building
It does the arithmetic, checks every combination of the modeled choices against your cash reserve, and replays each result. It has been tested on synthetic cases only.
A specialized model would frame the decision, find missing or contradictory evidence, state its uncertainty, propose actions and say when it cannot conclude. It would use the engine's numbers, never its own. Its training has not started; we will train it only where a comparison fixed in advance shows it is needed.
Every decision is the owner's. Qelly does not move money, lend or approve financing.
It may carry the conversation. It would not make the judgment or do the arithmetic.
We do not collect customers' finances to build a shared dataset, and we do not sell or share them with banks, insurers or lenders. We do not use your records to train shared models, and using Qelly gives us no right to do so.
Where Qelly is going
Some financial decisions are also security decisions: a supplier's bank details change, an unexpected invoice arrives, or a message that seems to come from the owner asks for an urgent payment. In a planned workflow, Qelly would advise holding the payment until the change or request is confirmed through a contact already on file. An unconfirmed change or request would stay unresolved, and the owner would decide whether to release or reject the payment. Qelly does not move money. Other defensive security decisions would come later, each with its own tools, permissions and tests.
The largest AI models that a business can run on its own hardware need far more powerful computers than most small businesses would buy. Our goal is for the judgment model described above to run on one machine the business controls, as a compact model that coordinates Qelly's checked tools, verifies their results and says when it cannot conclude, with no outside model in the loop. We will first compare existing open models; adapting one of them, with help from a larger model if needed, would follow only where that comparison shows a gap. We have not chosen a model.
Records a business keeps for years, such as its accounts and tax records, need protection that lasts. The private deployment would protect the connections it controls with the post-quantum methods NIST standardized in 2024, encrypt storage and backups with keys only the business holds, and sign each decision record so that a change to a signed record can be detected.
The workflow for changed payment details, the compact model and post-quantum protection are not yet built. This direction needs funding.
We can't find the internet
Attempting to reconnect
Something went wrong!
Attempting to reconnect