Technology with a job to do

A company can buy an expensive system and still prepare its cash forecast by copying numbers between spreadsheets on Friday afternoon. It can also run a disciplined process on modest software if the data has an owner, definitions are stable and the output is reconciled. Technology matters when it removes a delay, error or blind spot that changes a decision. The choice begins with the work, not the product demonstration.

The work in this book crosses several systems. A customer order becomes a production schedule; the schedule creates material requirements; purchases and receipts become inventory; shipments become invoices; invoices become receivables and, eventually, cash. Payroll, capital projects, taxes and debt service have their own paths into the forecast. A management report needs those paths to meet in a consistent period and currency. If each department has a different version of the order book, a faster dashboard merely publishes the disagreement sooner.

Map the decision and its data trail

Suppose a manufacturer needs to decide whether it can accept a large new program. Write down the decision first: price, capacity, investment, peak funding need and the last date at which the company can decline or stage the commitment. Then trace each input to its source. Which customer quantities are contractually firm? Which are forecasts? Which bill of materials and scrap assumption generate the input requirement? What is the supplier lead time, minimum batch and payment date? When can the line produce sellable units, and when will the customer approve and pay them?

A practical data dictionary gives each important field a meaning and owner. “Order date” might be the date the customer placed an order, the date it requested delivery or the date the company accepted it. “Inventory” might include goods in transit or exclude material held at a subcontractor. “Cash available” may mean bank balance before restricted deposits, overdraft use or uncleared payments. These distinctions sound small until the forecast relies on them. Agree the definition and record any exception rather than adding another formula that silently changes it.

Where an accounting system, enterprise resource planning system, customer portal and bank feed exchange data, define the interfaces and control totals. A daily import should show records received, rejected and duplicated. The opening bank balance plus receipts less payments should match the closing balance. The sum of customer subledger balances should match the ledger control account. The inventory movement report should reconcile to quantities and value, with differences investigated. A dashboard can be refreshed every hour and still be wrong every hour if no one owns those checks.

The thirteen-week cash forecast illustrates the technology choice. Start with the current bank position, open receivables by expected collection date, payroll and tax calendars, debt service, approved capital spending and purchase commitments. A spreadsheet may be sufficient for a smaller business if inputs have owners, versions are controlled, and forecast versus actual is reviewed each week. More automation may be justified when transaction volume, multiple entities or currencies make manual updates slow and error-prone. The software should preserve assumptions and exceptions so a forecast change can be explained, not merely recalculate a new total.

Choose the smallest system change that solves the problem

If the problem is late invoices, map the delay from delivery confirmation to invoice issue and customer acceptance. Perhaps the warehouse does not confirm shipment promptly; perhaps a customer requires a purchase-order reference the sales team omits. Automating invoice generation without fixing either step may send incorrect documents faster. If the problem is unreliable product margin, examine bill of materials, yield, purchase-price updates and overhead allocation before buying a reporting layer. A better chart cannot repair an incorrect cost base.

Make a business case for the change with the same discipline used for a machine. Include license or subscription fees, integration, data cleaning, training, parallel running, internal time and ongoing support. Name the expected benefit: fewer days to close, fewer invoice disputes, lower stock without worse service, or earlier detection of a cash shortfall. Put a baseline and a date beside it. “Better visibility” is an aspiration until someone can describe what will be seen earlier and what choice that permits.

Consider a fictional receivables process. Invoices are issued four days after shipment because delivery evidence is assembled manually. A workflow that reliably cuts the delay to one day may accelerate invoicing by three days. If annual credit sales are €12 million spread evenly over 365 days, three days of sales are about €98,600. That is a rough steady-state reduction in the funding tied to unbilled sales, assuming the customer's payment clock begins on invoice date and actual collection behavior does not offset the gain. It is not €98,600 of extra profit each year. The recurring economic benefit is the financing cost avoided on the released amount, plus any measured reduction in disputes or bad debt, less system and process costs. The distinction between cash released once and profit earned repeatedly matters in every technology proposal.

An implementation should use gates. First reconcile master data: customers, suppliers, items, units of measure, tax codes and opening balances. Then run representative transactions from order through receipt or collection, including returns, partial shipments, disputed invoices and a failed interface. Compare outputs with the existing process for a defined period. Authorize a cutover only when material differences are resolved and a fallback is understood. Record who can approve a configuration change and who checks that it works after deployment. “Go live” is the start of operating discipline, not the end of the project.

An AI portfolio that earns its place

My interest in machine learning began well before I knew how to build a model. At an asset manager in Minneapolis, I saw a neural network used to classify the credit quality of corporate bond issuers. It seemed like a black box with reasoning ability. I was fascinated and wanted to understand what was actually happening inside it, but work and life kept pushing the study aside.

Years later I heard about the 2017 paper Attention Is All You Need, which introduced the Transformer. I sensed it might matter. I also did not understand the paper at all. My first question was: how on this green earth does anyone build something like that? Python looked like a practical doorway, so I bought books and began learning it. The doorway was simpler than the room beyond it: the research, data, mathematics and engineering did not become easy because the code was written in Python. I eventually enrolled in a Python web-development program and then a machine-learning and AI program. As conversational large language models became widely available during that period, the reason to finish the journey became harder to ignore. I completed both programs and have continued studying agents and retrieval-augmented generation, which gives a model relevant documents to work with when answering a question.^[10]

I do not expect every CEO to take the same route or make AI a hobby. I do expect a business leader to be curious enough to ask what a tool can do for a real management routine, what data it needs, what mistakes it makes, what it costs and who may approve its actions. I cannot forecast all of AI’s long-run consequences, and enthusiasm does not excuse a weak test. My view is that the technology will be part of business practice; leaders who ignore it entirely will struggle to judge where it helps and where it creates a new risk. The applications below give that curiosity a specific job and a way to test the result.

I enjoy experimenting with agents. I have built small poker and chess projects in which several models take different roles or must agree on a move. The chess committee had me defending almost from the opening. Watching the models work through the game was fascinating; it did not make me hand them the ERP. In my current enterprise experiments, scripts may read data for controlled analysis, but I have not given agents permission to change records. Data permission, confidentiality, the cost of repeated model calls and an accountable human review are design constraints before an automated action is allowed. A game and a supplier payment have very different error budgets.

The practical sequence is to choose one decision, reconcile its inputs, run a read-only pilot against a baseline, measure errors and time saved, then decide whether a narrow write action deserves approval and monitoring. A striking demonstration of model reasoning is not a substitute for this test. My interest in the technology is a reason to learn and validate it, not a reason to release it unsupervised.

Application	Value to test	Human check
Invoice-query triage	Faster resolution	Original invoice and dispute
Cash collection forecast	Lower forecast error	Customer-level backtest
Contract search / summary	Quicker term review	Clause and source document
Credit-risk model	Earlier deterioration signal	Calibration and overrides

A pilot should have a baseline, a measured outcome and a stop rule. AI does not remove accountability for a bank submission, credit decision or financial statement. The CFO must know what the model saw, what it missed and who reviewed the result.

Protect access and the ability to explain a number

System permissions should follow roles. A user who records a supplier invoice may not need to edit bank details; a person who changes a customer limit should not also be the only reviewer of the override. Remove access when roles change. Use multi-factor authentication where available, keep backups and test that important data can be restored. These are operational requirements because lost access or corrupt data can interrupt shipments, billing and payments. Maintain a manual or alternate route for critical actions during an outage, with clear authorization and a later reconciliation.

Version control applies to spreadsheets as well as software. Keep a published forecast with an as-of date, source extracts and an assumptions log. Limit write access to key formulas and record material overrides. When a new forecast is approved, preserve the old one so management can distinguish a changed business from a changed model. A hidden formula that overwrites a prior assumption can erase the evidence of why a funding decision was made.

The audit trail should answer a plain question: why did this number change? A jump in margin could come from a better selling price, a new product mix, a delayed supplier invoice, a cost-master update or a formula error. The system may capture who changed a field and when, but management still has to identify the business reason. Define who reviews unusual manual journals, unit costs, credit notes, stock adjustments and bank-detail changes. Exception reporting is useful when the exception is investigated and resolved, rather than carried in a queue indefinitely.

Use automation and AI with a clear boundary

Automation can copy routine data, match invoices against orders, flag overdue accounts and refresh reports. Machine learning or generative AI can help summarize a long variance listing, classify disputed invoices, draft a first explanation or suggest questions for management. These are aids to analysis. Before relying on the output, compare it with the ledger, source documents and the decision's materiality. A convincing sentence about a price variance is not evidence that the underlying price, quantity and period are correct.

Do not hand an automated system authority it has not earned. A model can propose a cash-collection priority; a responsible person decides how to approach a customer. A tool can identify a suspected duplicate payment; a reviewer confirms it before withholding a legitimate supplier payment. Never allow a generated message alone to change beneficiary details or release funds. Sensitive customer, employee and banking data also need appropriate access, contractual handling and retention rules. The economic case for speed is weakened quickly by a preventable error or loss of trust.

Keep a human-readable calculation for the most important decisions. A CEO should be able to trace the peak cash need for a new program from volumes and dates, even if a system produces the number. The purpose is not to rebuild every report by hand. It is to know which assumptions matter, which records support them and what would break the conclusion. If no one can explain why a forecast fell by €500,000 after a software update, the forecast is not ready to guide a financing conversation.

Build an AI capability in stages

AI deserves a place in financial strategy because it can change the speed and reach of analysis, but its value depends on the task. A useful progression is to automate a repetitive data flow, add statistical prediction where past patterns contain signal, use language models to work with documents and explanations, and only then consider agents that act across systems. These are not mandatory steps in a technology race. Each stage should solve a named problem, have a measured baseline and retain a human decision maker for material financial consequences.

The data foundation comes first. Define customer, product, transaction date, currency, unit of measure and the authoritative source of each field. Reconcile historical snapshots before training a deterioration model or asking a language model to explain a variance. Otherwise a more capable model merely processes a larger quantity of contradictory input. Finance should own definitions and tests jointly with technology colleagues; it should not expect a vendor to infer the company’s accounting and commercial meaning from column names.

Choose the method to fit the question. A deterministic rule is often best for a covenant calculation or an approval threshold. A conventional forecasting model can be easier to validate than a deep network when the data set is small. Machine learning may be valuable for customer payment behavior, anomalies, credit deterioration or demand, provided outcomes can be measured out of sample and the model is recalibrated as conditions change. A language model is better suited to finding clauses, drafting a first explanation or comparing unstructured documents. It should cite the underlying records for a material assertion. An agent that can edit a payment file or release an order requires explicit permissions, logging, exception handling and approval boundaries.

My own learning in AI has reinforced a practical point: building a working model is not the end of the job. One must understand what the training data represent, how labels were produced, whether the test period reflects future use, and what happens when the input distribution changes. A fast or accurate result on a benchmark does not establish that a finance team can rely on it in a lending or cash decision. The question is whether it improves the decision after its errors, costs and review effort are included.

For each proposed use case, record the owner, decision affected, current process, expected benefit, allowed data, validation test, fallback process and review frequency. A pilot that sorts invoice queries might be judged by time to resolve disputes and error rate. A cash collection model should be judged by its forecast error across customers and stressed periods, not by how convincing its narrative sounds. A contract assistant should be tested on whether it finds the correct clause and states its limits. A credit model needs calibration, monitoring, documented overrides and a way to explain adverse outcomes.

A build-versus-buy decision should compare integration, maintenance and control as well as license cost. Buying a mature tool can speed adoption when its data model matches the business. Building may be sensible for a distinctive process or a small, testable model that can be maintained internally. The hidden cost in either route is often cleaning and governing data, changing workflows and training people to challenge outputs. Management should approve a phased investment with a stop rule, not a large project justified by a generic promise of efficiency.

I would organize the first year around a small portfolio: one low-risk productivity task, one forecast or anomaly task with a measurable backtest, and one controlled experiment that helps managers search and explain financial evidence. Review actual usage and decisions changed, not only model accuracy. Retire a tool that creates review work without improving outcomes. Expand a successful one only after access, audit trail, backup and ownership are settled. The ambition is a finance function that learns and acts faster while remaining able to show why a number is right.

Review the result after the system settles

Measure the outcome against the original reason for the investment. If the objective was a faster close, compare the actual close dates and the number of unresolved reconciling items. If the objective was better inventory planning, compare service levels, stock days, obsolescence and emergency purchases together. A lower inventory balance achieved by missed deliveries is not an improvement. If the objective was collections, track invoice timing, disputes and actual receipt dates, separating customer behavior from the internal process.

Technology can make the laws of financial gravity more visible: the material committed before a customer order is firm, the weeks between shipment and cash, the ramp before new capacity earns its cost. It cannot repeal those laws. Build systems around the decisions and controls the business needs, then use what they reveal. The final measure of a technology project is whether management sees the relevant consequence sooner and has a better chance to act.

A staged route from spreadsheet to dependable report

First choose one decision that currently suffers from poor information. A manufacturer might choose the weekly cash low point or the margin on customer-specific work. Write the existing process on one page: source records, people who edit them, manual transfers, reconciliation, report date and decisions delayed by it. Measure the baseline, such as hours spent, number of corrections or days between shipment and invoice. A system proposal that cannot name its current failure is unlikely to prove its success.

Next create one controlled dataset with stable identifiers for customers, products or services, sites and periods. Decide which system is authoritative for each field. Map returns, credit notes, work in progress, taxes, late invoices and currency changes explicitly. For a product margin report, the invoice, effective bill of materials and cost basis must agree; for a service margin report, the contract, timesheets, subcontractors and billing milestones must agree. Reconcile the output to the detailed records and ledger before calling the chart a result.

Only then automate routine refreshes and add visual summaries. Keep a timestamp, record count and control total on each import. Send failed or incomplete loads to a named owner and prevent an old dashboard from appearing current. A narrow pilot might cover ten critical materials in two customer programs, or ten delayed service invoices across two client teams. Compare its forecast or exception list with the existing process before expanding. The first release earns a wider audience by being useful and explainable.

Roll out access by role, with approval for new users and periodic review. Train people on what a report means and which exceptions they must correct. For a critical cutover, keep a parallel run long enough to compare revenue, stock, receivables and cash, and decide in advance what differences block release. Preserve the ability to reconstruct the last reliable position if an interface fails. After a few months, compare the promised decision improvement with the baseline; retire redundant reports rather than leaving staff to maintain the old and new processes forever.

Keep the financial case honest

Suppose a reporting project costs €120,000 to implement and €24,000 a year to operate. The proposal claims it will release €400,000 of inventory through better scheduling and reduce overtime by €30,000 a year. The inventory release is a one-time cash effect if achieved and sustained; the overtime saving is an annual operating benefit. At a 10% illustrative financing cost, the inventory release also avoids about €40,000 of annual carrying finance cost while it remains released, but do not count both the full €400,000 as annual profit and the €40,000 as if they were independent recurring sales. Include obsolescence, storage and service effects if measurable, and test whether the same scheduling change would have been possible without the software.

The proposal is attractive only if the operational assumptions hold. Identify which stock categories can really fall, the timing of purchase reductions, whether supplier minimum batches prevent them, and the effect on on-time delivery. Let the production and purchasing owners sign up to those assumptions. Review actual stock and overtime after implementation. A report that shows a lower reorder point but does not change purchasing behavior has produced insight without the promised cash.

Retire obsolete measures as the system improves. A new platform can produce hundreds of metrics; keep the few that help management see earning power, conversion to cash, funding needs and risk. Data governance sounds grand; in practice it means someone owns the meaning of “firm order,” someone checks the import, and someone can explain why the forecast changed on Tuesday. AI adds a further test: it must meet those same standards before its proposed answer or action enters a management process.

A measured AI rollout

Stage one establishes a common data dictionary and reconciled extracts. For each customer, product and material, agree identifiers, effective dates, currency, unit of measure and ownership. Reconcile sales, cost, stock and receivables to the general ledger at a defined cut-off. Document manual adjustments. This work is unglamorous, but it prevents a sophisticated application from scaling the same inconsistencies that lived in spreadsheets.

An AI pilot needs dated gates and a baseline. The example below is a proposed twelve-month roadmap for a non-AI business, not a report of an achieved saving in the author’s company. Use only approved extracts at first. Store the extraction time, data lineage, prompt or code version and human correction so that a faster answer can still be traced to an invoice or purchase order.

Time	Deliverable and owner	Pass measure	Permission / gate
M0–2	Reconcile AR/AP, bank and stock / controller	≥99.5% value tied; exceptions logged	Read-only test data
M3–5	13-week draft forecast / treasury	Beat manual error; cut hours ≥25%	Human publishes every version
M6–8	Forecast variance and scenario / FP&A	Two cycles of dated back-test	No ERP write access
M9–12	Limited workflow review / CFO + IT	No unreviewed material action	Approve scope or stop pilot

Figure 16.1. An AI draft reaches the operating system or an external party only after a named person reviews the evidence and approves the action.

Measure forecast error at the same horizons and against the same actual bank movements as the manual baseline; segment disputed customers and long-lead purchase orders. Review false negatives, especially missing cash obligations. Security staff must approve data classification, provider terms, retention and access before any model receives company records; budget repeated calls and record the cost per usable forecast. A proposed write action needs separate authorization, restricted rights, rollback and audit evidence. If reconciliation or accuracy fails, improve the source process or stop rather than granting broader permissions.

Stage two automates one decision flow, such as the thirteen-week cash forecast. Connect bank balances, open invoices and supplier obligations, while leaving an explicit manual review for disputed collections and purchase commitments absent from the ledger. Compare the automated forecast with the prior process over several cycles. Measure forecast error, preparation time and the time from a new customer delay to an updated cash view. An application that saves two hours but omits firm purchase orders may be a net loss.

Stage three expands to scenario planning: customer release changes feed material needs, capacity, margin, working capital and cash. Each link should be testable. If a customer postpones 100,000 units, the model should show which material orders remain firm, which machine hours are freed, which variable costs disappear and which debt payments remain. Users should be able to inspect and override assumptions with a reason. This is more useful than a “one-click forecast” whose outputs cannot be traced when they matter.

Finally review the implementation against the original business case. Did it reduce late purchases, forecast misses or manual reconciliation? Are managers using it in meetings, or have they returned to private spreadsheets? What controls failed and what data still needs human judgment? Technology earns its place when it shortens the path from a changed fact to a better decision. It cannot change the payment date on a loan, create customer demand or make long-lead material vanish. It can make those constraints visible soon enough for management to act.

Sources and notes

10. Transformer. The 2017 paper introduced the Transformer architecture. The author’s account describes hearing about and later studying the paper, not claiming participation in its research. Attention Is All You Need, Google Research