Why traders start in Excel
Excel — or Google Sheets — is the natural tool for any trading team starting out: flexible, everywhere, and happy to let you improvise a column as the business changes. For an operation with a few deals a month and one person running it, that is perfectly sensible.
The problem is not Excel: it is the moment it falls short. And almost nobody catches that in time, because migrating “hurts now” while the cost of staying shows up diffusely in errors, rework and margins that evaporate.
Where Excel stops being enough
As the business grows, the classic problems are:
- Broken formulas after a copy-paste or a row inserted outside the summed range.
- Currency conversions with rates typed by hand, with no date and no source, that nobody can justify months later.
- Forgotten costs: port charges, certificates or bank fees that turn up late and eat the margin.
- Parallel versions of the same file circulating by email with nobody sure which is the real one.
- Cell-level traceability: version history exists, but it tells you someone changed D42 from 1,080 to 1,120 — not that the real freight on deal GR-2041 changed, which is the question you actually have.
- Reporting rebuilt every time: if each close means reconciling, refreshing and laying out the same information by hand, that time comes back every month.
- Concentrated knowledge: when only one or two people understand how the file hangs together, onboarding anyone new is hard and holidays are frightening.
Quick comparison table
| Function | Excel / spreadsheet | CTRM (Granel) |
|---|---|---|
| Per-deal P&L | Possible; depends on the model the team builds and maintains | Calculation built into the deal model |
| Multi-currency (EUR, USD, COP…) | Possible with a rate table and careful references | Reference rate and applied rate, with date and source per deal |
| Change history | Version history and “show changes” in OneDrive or Sheets, at cell level | Logged per user, deal and field, readable from the deal itself |
| Concurrent work | Co-editing available in the cloud; governance depends on the file | Users, roles and permissions over business entities |
| Cost lines | The structure is defined and held together by whoever built the sheet | Normalised cost lines per deal, based on tonne, container or shipment |
| Documents (B/L, invoices, certificates) | Folders or links to an external file manager | Attached to the deal they belong to |
| Position, mark-to-market and FX exposure | Requires building and maintaining a separate valuation model | Open position, unrealised P&L against a reference price, and forward exposure |
| Cashflow at 30/60/90 | Requires building the model and refreshing it every close | Consolidated view, nothing to assemble |
| Alerts and anomalies | Can be built with validation, conditional formatting or macros | Rules per deal and deviation against your own history |
| Reporting | Very flexible, but it has to be maintained | Standard views and exports |
| Who maintains the logic | Your team, with their time | The vendor, with the subscription |
The 7 signs it is time to leave Excel
- The critical logic is spread across several sheets or files and only one person understands how they connect.
- More than one person needs to edit deals at once and the file is not built to govern that.
- You have had at least one margin error traceable to a broken formula or a copy-paste.
- Every period close means reconciling and laying out the same information by hand again.
- You trade more than one currency in the same deal and nobody can say which rate was applied or why.
- You need to know your open position or exposure and the sheet cannot tell you.
- Someone new is joining and knowledge of the file lives in one or two heads.
None of them forces a migration on its own, and counting them is not a calculation. If you recognise several, what is worth doing is the real arithmetic: the hours spent maintaining and reconciling the sheet, plus the expected cost of errors, against the subscription plus implementation. When the first consistently exceeds the second, switching pays; before that, it does not.
How Granel handles each of those points
- Native multi-currency: daily rates from reference sources — the ECB reference exchange rate via Frankfurter, plus a complementary source for currencies the ECB does not publish, such as the Colombian peso — storing per deal the rate applied, its date and its origin. Conversion stops depending on loose cells and somebody’s memory.
- Per-deal P&L broken down by cost line, with GP on one definition throughout the product — deal page, list, analytics, export and API: sale minus purchase minus the deal’s cost lines. Below it, EBIT: GP minus the overhead per tonne each organisation sets, with EBIT % of sales.
- Position, mark-to-market and exposure: open position per product, unrealised P&L valued against the latest reference price, and forward FX exposure with scenario simulation.
- Deal settlement: estimated costs are reconciled against actuals as the invoices arrive, instead of overwriting the same cell.
- Full audit trail: every change is recorded with user and timestamp.
- Role-based permissions so each team member edits only what is theirs.
- Automatic alerts when a cost line deviates from your history or a margin drops below a threshold.
- Consolidated cashflow at 30/60/90 days in one view, with no pivot tables.
- CSV/Excel exports to keep your accountant or your ERP fed.
When staying in Excel STILL makes sense
Not every team needs to migrate. Staying in Excel makes sense if:
- Volume and complexity are low and one person controls and reconciles the whole cycle without significant manual work.
- Your entire operation runs in a single currency with very stable terms.
- You do not expect the team to grow in the next 12 months.
In that case the best return usually comes from cleaning up and protecting the spreadsheet you already have — validation, version control in Drive or OneDrive, a per-deal template — rather than buying a CTRM.
Further reading
If your question is not Excel but your ERP, the CTRM vs ERP comparison may help. If you are still getting the concepts straight, read the full guide on what a CTRM is or check the definitions of CTRM, P&L, Incoterms and FX in the glossary.
Frequently asked questions
Is Excel really a bad place to run commodity deals?+
Not out of the gate. Excel is flexible and cheap to start with, and a well-built sheet — tables, validation, version control — goes much further than people usually admit. The problem is not capability, it is maintenance: your team designs, documents and sustains that logic, and the cost shows up when volume grows, new people join, or nobody remembers why a cell says what it says.
When is the change most noticeable?+
Measure it rather than assume it. Four things are worth taking before migrating and again afterwards: time to close a deal, number of margin corrections, how long a new joiner takes to work unaided, and the gap between forecast and actual cashflow. If they do not improve, the migration was not worth it — and you should be able to see that too.
Do I have to migrate my whole spreadsheet history to start?+
Not all of it. What is worth migrating from day one is master data — products, counterparties — and open operations with their outstanding balances and costs: without that there is no operational continuity. Closed history can be uploaded in batches in a second phase. That avoids the classic never-ending “migration project” and lets you get operational value before it is finished.
What if my CFO or accountant only wants Excel?+
A CTRM does not replace the accounting export: it lives alongside it. Most teams export the monthly summaries — P&L, cashflow, VAT — to CSV/Excel to send to their accountant or load into the ERP. What gets replaced is the “master spreadsheet” where all the deals live, not the reports.
What does a CTRM cost against “free” Excel?+
Excel is not free: it costs team time, hidden errors and opportunities missed for lack of visibility. A CTRM like Granel starts at €149/month for small teams. To know whether it pays off in your case, do the arithmetic with your own numbers: on one side, the hours spent maintaining and reporting times their hourly cost, plus the expected cost of errors; on the other, the subscription plus amortised implementation. When the first consistently exceeds the second, migrating makes economic sense.