Operating Systems

How to automate cash flow forecasting and inventory management

Automation doesn't buy you a better prediction. It buys you a shorter distance between a fact changing and you knowing what it changes.

AmazeBase 12 min read Inventory & Cash Flow

Six inputs feeding one engine that turns inventory into a dated cash forecast

Most sellers who ask this question are really asking two questions at once.

The first is mechanical: can software do the arithmetic for me? Yes. That part was solved decades ago.

The second is the one that matters: can I trust the answer enough to spend $40,000 on it?

Automation doesn't earn that trust by predicting better. It earns it by shortening the distance between a fact changing and you knowing what that fact changes.

A supplier slips two weeks. A competitor goes out of stock and your velocity doubles. A container lands early. Each of those changes one number — and every decision downstream of it. In a spreadsheet, you find out when you next open the spreadsheet. In a system that's wired together, you find out that day.

That's what automation buys. Not certainty. Speed of correction.

Here's how to build it, in the order that actually works.

00What "automated" actually means

A system that automates cash flow and inventory has to do four things, in this order. Skip one and the rest is decoration.

  • Collect — every fact arrives without you retyping it.
  • Date — every fact carries the day the money moved or the unit sold, not the day you noticed it.
  • Decide — the system converts facts into a dated action, not a number on a chart.
  • Compare — last week's answer is kept and scored against what actually happened.

Most tools stop at collect and call the chart a forecast. The value is in the last two.

A forecast that doesn't end in a date and a quantity isn't a forecast. It's a mood.

Connect the six inputs

Cash and inventory forecasting need exactly six inputs. Three of them Amazon knows. Three of them only you know — and those three are why generic tools give generic answers.

Amazon knows

  • 01Units sold, by SKU, by dayYour real demand signal — including the days you were out of stock.
  • 02Settlement money in and outSales, refunds, referral fees, FBA fees, storage, disbursements — dated as Amazon charged them.
  • 03Stock on hand and in transitFulfillable, reserved, inbound, plus the ledger of every movement.

Only you know

  • 04Landed unit costManufacturing, freight, duty, inspection — per unit, per batch. Not an average you typed once.
  • 05Real lead timesDays from you placed the order to Amazon made it sellable, per supplier, measured across your last several orders.
  • 06Payment terms30% at order, 70% at shipment, net 30 after arrival. This is what turns a purchase order into a dated cash outflow.

Inputs 4 to 6 are the whole game. A tool that only reads your Amazon account can tell you what happened. It cannot tell you what you can afford, because it doesn't know what you owe or when.

What to do

Enter costs, lead times and payment terms once, at the moment you place the order — not at month end. If it isn't captured when the PO is created, it never gets captured.

Make the numbers honest before you automate them

Automating a wrong number just produces wrong answers faster. Four rules make the inputs trustworthy.

Anchor to the data, not to the calendar

If your last transaction file ends 12 days ago, your "daily sales" figure is the average of 12 real days and 12 days of zero. That silently halves your velocity — and a system that then divides your stock by that velocity will tell you your inventory lasts twice as long as it does.

Every rate must be computed against the last day the data actually covers, and the screen must say what that day is. Freshness is not a footnote; it's a precondition.

Money in, money out — nothing allocated

A P&L that tries to attribute every cost to a product will spend your life adjudicating allocations that don't change a single decision. For cash forecasting, a cost is a cost on the day the money moved. Which ASIN it belongs to is a separate question, asked by a separate screen.

This one rule removes most of the reconciliation work that makes sellers abandon their own numbers.

Label certainty; never launder it

Not every future dollar is equally real. Three bands are enough:

ConfirmedPaid, with a date on the receipt.
ScheduledUnpaid, but the trigger and due date are known.
AssumedA cost we know exists, with no schedule attached, dated on a default.

Show them separately and stack them. A cash chart where these are mixed into one bar is worse than no chart, because it looks like knowledge.

Where facts disagree, the human resolves it

Two records will contradict each other: your receipt count against Amazon's, your freight invoice against the shipment it belongs to. Software that silently picks a winner is software you will eventually stop believing.

The right behaviour is to surface the conflict, refuse to average it away, and put a barrier in front of the wrong answer — while leaving the decision with the person who knows.

Inventory: turn stock into a dated decision

Now the arithmetic. Note the order: the date comes before the quantity.

Velocity, with a window you can defend

Use exact trailing windows — 7, 30, 60, 90 days — anchored to the last data date. Weight the recent window more heavily than the long one (something like 60/40 on 7-day against 30-day) so a real trend shows up in days rather than months, and fall back to longer windows when a SKU is too thin to read.

Never use a lifetime average. A product that sold 20/day in January and 80/day in March does not sell 47/day.

Days of cover, and the stockout date

days of cover        = stock on hand / daily velocity
days of cover (net)  = (stock on hand + inbound) / daily velocity
projected stockout   = last data date + days of cover

The inbound line matters more than sellers expect. Units on a boat are not stock, and are not nothing.

Lead time: measure it, don't type it

The single biggest source of error in reorder timing is a lead time somebody typed in once, in optimism, in a different year.

Measure it from your own history: order date → the date units became sellable, per supplier, and keep both the average and the worst case. The gap between the two is not trivia — it is exactly the size of the safety stock you need.

Safety stock is a purchased service level, not "extra"

safety days   ≈ (worst lead time − average lead time)
                + demand-variability buffer

reorder point = velocity × (average lead time + safety days)

order-by date = last data date
                + (days of cover − average lead time − safety days)

If the order-by date is in the past, the order is overdue, and the system should say so in those words.

Only then, the quantity

suggested qty = velocity × (lead time + target cover)
                − stock on hand − inbound

Target cover is a business choice — how many days of stock you want on hand when the shipment lands. Where you have a real per-order freight cost and a real holding cost, the economic order quantity tells you whether your habitual order size is costing you money:

Q* = √( 2 × annual demand × cost per order
        / annual holding cost per unit )

Treat EOQ as a check on your instinct, not a command. It assumes steady demand, and yours isn't.

Show the composition, not just the number

"Order 1,400 units" is unauditable. "1,400 = 62/day × (45-day lead + 60-day target cover) − 3,100 on hand − 1,200 inbound" is a number a seller can argue with — which is the only kind worth acting on.

Cash: turn a P&L into a dated timeline

A profit and loss statement tells you whether the business works. It does not tell you whether you can pay for the container. Those are different questions and they need different screens.

A cash timeline needs four streams, each dated.

Money in

  • Amazon disbursements — your settlement balance, released on Amazon's cadence, which lags the sale. Model the lag; don't pretend the sale date is the cash date.
  • Any non-Amazon revenue.

Money out

  • Supplier instalments — driven off the PO's payment triggers: at order, at shipment, N days after shipment, on date. This is the one that ruins quarters.
  • Amazon's own deductions — fees, ads, storage — which mostly net out of the disbursement rather than arriving as a bill.
  • Overheads — the ones with no product attached: software, VAs, agencies, your own draw.

Start from a known opening balance on a known date. A cash chart with no starting balance is a chart of differences pretending to be a position.

Then the output is one line: your projected balance, week by week, with the lowest point and the date it happens called out. That trough is the number that decides whether an order is possible.

The join: an order you can't finance isn't a plan

This is the part almost every tool skips, and it's where the two halves of this article become one system.

Your inventory module says: order 1,400 units of SKU-A by the 14th, and 900 of SKU-B by the 22nd.
Your cash timeline says: your balance bottoms out at $8,200 on the 19th.

Separately, both are correct. Together, they're a decision:

  • Placing both orders on time takes the trough negative on the 19th.
  • Delaying SKU-B by nine days costs roughly six days of stockout — a countable number of units and dollars of contribution — and keeps the trough positive.
  • Splitting SKU-A into two shipments raises freight per unit but flattens the outflow.

That comparison — the order you should place versus the cash you'll actually have — is the whole point of connecting the two systems.

Ranking is capital allocation. When you can't fund everything, fund the SKUs with the highest return per dollar per year: contribution per unit × units sold per year ÷ dollars tied up. A 40% margin product that turns twice a year loses to a 20% margin product that turns six times.

What to do

Never look at a restock list without the cash trough on the same screen. A reorder suggestion that ignores your bank balance is a wish list.

Scenarios, and what they're actually for

Scenario tools get sold as prediction engines. They're not, and pretending otherwise is how sellers get burned.

Their real job is fragility testing: finding which assumption, if wrong, hurts most.

Run your plan with:

  • lead time at its worst observed value, not its average
  • velocity at ±30%
  • a supplier instalment landing two weeks earlier than promised
  • ad cost per sale up 20%

Then read the output as a ranking, not a forecast: my plan survives a demand miss but not a lead-time miss. That tells you where to buy insurance — an air-freight top-up, a renegotiated deposit, a smaller first order.

The single most useful scenario knob is not price. It's conversion rate. You can't measure whether new photography works, but you can measure what a one-point conversion change does to your stock cover and your cash trough — and that number is usually far larger than sellers expect.

Forecast vs. actual: the loop that pays for itself

Everything above is worthless if nothing keeps score.

Every week, store what the system predicted: velocity per SKU, projected stockout date, suggested order-by date, projected cash trough. Then compare it to what happened.

Three questions, asked on a schedule:

  1. Where was velocity wrong, and in which direction? Consistent one-directional error is a settings problem, not bad luck.
  2. Where was lead time wrong? Every completed PO is a free measurement. Feed it back automatically.
  3. Where was cash wrong? Almost always a payment whose trigger date was never entered.

Systematic error is a fixable defect. Random error is the cost of doing business. You cannot tell them apart without the record.

What you should never automate

Automation should shorten the distance between a fact and a decision — not take the decision.

Automate: collection, dating, arithmetic, alerting, the score-keeping loop.

Never automate — placing the order
A stockout costs you sales. A wrong $40,000 order costs you the quarter.
Never automate — resolving contradictory records
Surface the conflict; let the person who knows decide.
Never automate — inventing data you don't have
If freight per order was never measured, the honest output is "not measured" — not a plausible default silently doing the arithmetic.

An empty state that tells you what's missing is worth more than a full screen built on assumptions.

A 30-day sequence to set this up

  1. Week 1 — Truth. Get transactions and the FBA inventory ledger loaded. Confirm the last data date. Fix stock discrepancies. Nothing downstream is real until this is.
  2. Week 2 — Cost. Enter your open purchase orders with real landed costs, real payment triggers and real dates. Back-fill the last three completed POs so lead time has something to measure.
  3. Week 3 — Decisions. Turn on reorder dates and days of cover. Set target cover per SKU deliberately. Check the composition of each suggestion against your own judgement — you're calibrating the system, not obeying it.
  4. Week 4 — Cash. Enter an opening balance. Build the timeline. Find the trough. Then put the restock list next to it and see which of your planned orders survives.

From there it's a weekly rhythm: what changed, what's overdue, what's affordable, and where was I wrong last week.

Frequently asked

Can cash flow forecasting be fully automated for an Amazon business?

The collection, dating and arithmetic can be. The inputs cannot: landed costs, supplier payment terms and your opening balance exist only in your records. Expect an hour of setup per supplier and a few minutes per purchase order thereafter.

What data do I need before I can forecast anything?

Six things: units sold by day, settlement money in and out, stock on hand and inbound, landed unit cost, measured supplier lead times, and payment terms. The first three come from Amazon; the last three come from you.

How accurate is automated inventory forecasting?

Accurate enough to beat a spreadsheet, and never accurate enough to trust blindly. The measurable win isn't forecast precision — it's the reduction in time between something changing and you responding, and the elimination of arithmetic errors in the response.

What's the difference between a P&L and a cash flow forecast?

A P&L tells you whether the business is profitable over a period. A cash flow forecast tells you whether you can pay for something on a specific day. A profitable Amazon business can absolutely run out of cash — that's the normal failure mode, not the exotic one.

How do I calculate a reorder point?

Velocity × (average lead time + safety days), where velocity is a recent trailing average anchored to your last data date, and safety days come from the gap between your average and worst-case measured lead time. Compute the date first; the quantity follows from it.

Why does my forecast keep saying I have more stock than I do?

Usually one of three things: velocity computed against the calendar instead of the last data date, inbound units counted as sellable, or a lead time typed in once and never measured.

Faster at correcting, not better at predicting

Automating cash flow and inventory forecasting isn't about buying a crystal ball. It's about building a system where every fact you already have is dated, connected, and pointed at a decision — so that when reality moves, you find out this week rather than next quarter.

The sellers who do this well aren't better at predicting. They're faster at correcting.