CFO ERP Decision Guide
By AAKoryx ConsultingPublished
ERP selection for CFOs, in five points
- Treat ERP selection as a financial decision first: it determines how transactions become financial records, which controls apply and how quickly the numbers can be trusted.
- Agree the decision criteria before looking at software, and apply the same criteria to every option.
- Compare options on multi-year total cost of ownership — including your own team’s time and the cost of today’s workarounds — not on licence price.
- Test every candidate on your own scenarios: an order through to the ledger, an inventory adjustment, a full month-end close.
- Much of the risk sits in scope, ownership and data. Settle those before implementation begins.
Why ERP selection belongs in the CFO conversation
Short answer
An ERP decides how transactions become financial records, which controls apply to them and how quickly leadership can trust the numbers. That makes selection a financial decision first: the software choice follows from the cost, control and risk requirements the business sets.
ERP projects are often framed as technology upgrades. In practice they change how orders, inventory, purchasing, production and billing reach the general ledger. The CFO is accountable for the integrity of that chain — and for the cost and risk of changing it.
Finance does not need to own every configuration decision. It does need to own the criteria: what the system must make visible, which controls it must enforce, what it may cost over its life and how much implementation risk the business can absorb.
Readiness is a separate discipline from selection.Read: ERP readiness is a business discipline decision
The CFO ERP decision framework
Short answer
Seven decisions, in order. Each has a question finance should be able to answer and evidence to ask for before moving on. The rest of this guide covers each step in more depth.
| Decision area | Finance’s question | Evidence to ask for |
|---|---|---|
| 1. Business case | Which visibility, control and efficiency problems must the ERP solve — and what do they cost today? | A written problem statement, with today’s workarounds and the effort they take |
| 2. Process scope and ownership | Which end-to-end processes are in scope, and who owns each one? | Process maps with a named owner for each process |
| 3. Decision criteria | What will we compare options on, and how will we weigh it? | Criteria and weightings agreed by the steering group before any demonstration |
| 4. Total cost of ownership | What will each option cost over its life, including our own time? | A multi-year cost model for each option, built on the same assumptions |
| 5. Fit on our scenarios | Does the system handle our transactions, controls and close — not a scripted demo? | Demonstrations run on your own scenarios and sample data |
| 6. Implementation risk | Where could cost, timeline or data quality go wrong, and who manages it? | A risk register, data plan, integration inventory and partner plan |
| 7. Decision and governance | Who decides, on what evidence, and how will scope changes be controlled? | A recorded decision, defined decision rights and a change process |
Want a quick read on where you stand before you start?Check where your organization stands — take the 3-minute assessment
What belongs in ERP total cost of ownership
Definition
ERP total cost of ownership (TCO) is every cost of acquiring, implementing, running and changing the system over a realistic multi-year horizon — including your own team’s time — set against the cost of the workarounds it should remove.
| Cost area | What to include | Often missed | Question to ask |
|---|---|---|---|
| Software and licensing | Subscription or licences, editions, applications, user types | How cost changes as users, companies or applications are added; renewal terms | How will our cost change if we add users, applications or companies? |
| Hosting and operations | Cloud or hosting fees, monitoring, backups, security | Who operates and secures the system if it is self-hosted | What does hosting include, and what must we run ourselves? |
| Implementation | Process design, configuration, project management, testing | Discovery and design work that precedes configuration | What is in the estimate, what is excluded, and what triggers a change order? |
| Data migration | Cleansing, mapping, loading and validating master data and opening balances | The internal effort to fix data before it moves | Who cleans the data, and how will opening balances be validated? |
| Integrations | Connections to banks, eCommerce, shipping, payroll and other systems | Maintenance when a connected system changes | Which integrations are standard, which are built, and who maintains them? |
| Customization | Functionality built beyond standard capability | Keeping custom code working through future upgrades | What will it cost to keep this customization working after an upgrade? |
| Internal team | Time of finance, operations and IT staff in workshops, data work and testing | Backfill or overtime while key people are on the project | How much of our people’s time does this plan assume? |
| Training and change | Training, documentation and process change | Adoption support after go-live | How will users be trained, and what support follows go-live? |
| Support and upgrades | Ongoing support, version upgrades and enhancements | Upgrade effort over the system’s life | What does a major-version upgrade involve, and who carries the effort? |
| Cost of today’s workarounds | Manual reconciliation, spreadsheet reporting, re-keying, errors and delays | Decisions made late or on unreliable numbers | What does our current process cost each month in time and rework? |
Use the same horizon and assumptions for every option. Give implementation, customization and internal effort their own lines: they can differ between options as much as licence cost does. The aim is a fair comparison, not a precise forecast.
How to compare ERP platforms beyond licence price
Short answer
Compare platforms on how they will behave over the life of the system — licensing as you grow, implementation, customization, integration, upgrades, controls and support — and ask every vendor and partner the same questions.
| Criterion | Why it matters to finance | Ask any vendor or partner |
|---|---|---|
| Licensing model | Determines how cost moves with growth | How is pricing structured — by user, application, company or volume — and what changes at renewal? |
| Implementation model | Shapes cost, timeline and risk | Who implements, with what method, and how is scope controlled? |
| Customization | Custom code has to be maintained through upgrades | Which of our requirements need configuration, process change or custom code? |
| Integration architecture | Connected systems carry their own cost and failure points | How do integrations work, and who maintains them when either side changes? |
| Upgrade model | Version changes affect cost and disruption over the system’s life | What does a major upgrade involve, how often, and who carries the effort? |
| Data ownership and portability | Affects reporting, audit and exit options | How do we access and export our data, and in what formats? |
| Reporting | Management reporting should come from system data | Can we produce our management pack from the system, without spreadsheets? |
| Controls | Controls must be enforced by the system, not by people | Show us access rights, approvals, period locks and the audit trail on our scenarios. |
| Operational fit | Financial accuracy depends on operational transactions | Run our order-to-cash, procure-to-pay and month-end on our sample data. |
| Support model | Someone has to own the system after go-live | Who supports us after go-live, and how are issues prioritized? |
Financial controls an ERP should enforce
Short answer
Controls should be enforced by the system as configured for your business — not remembered by people. During evaluation, ask to see each control working on your own scenario.
| Control | What good looks like | Ask to see it |
|---|---|---|
| Role-based access | Users can do what their role requires and no more; changing access is restricted | Show how a buyer’s rights differ from an approver’s, and who can change them. |
| Segregation of duties | Creating, approving and paying are separated | Show that the person who enters a vendor bill cannot also approve and pay it. |
| Approvals | Purchases, payments and credit above set limits require approval | Show the approval path for a purchase above our limit. |
| Audit trail | Changes to accounting records show who, when, and the values before and after | Change a key field on a posted record and show us the trail. |
| Period locking | Closed periods cannot be changed without authorization | Lock last month and try to post into it. |
| Reconciliation | Bank, receivables, payables and inventory reconcile to the ledger | Reconcile a bank statement and show how unmatched items are handled. |
| Multi-company and currency | Entities and currencies are handled where your structure needs them | Post a foreign-currency invoice and show how it is revalued and reported. |
If a control cannot be demonstrated on your scenario during evaluation, treat it as a gap until it is.
Inventory valuation, COGS and operational-to-financial integrity
Short answer
For organizations that buy, make, store or ship products, inventory is where operations and finance meet. Evaluate when stock movements become accounting entries, how inventory is valued and when cost of goods sold is recognized — on your own transactions.
| Area | What finance should evaluate | Ask to see it |
|---|---|---|
| Valuation timing | Perpetual valuation (updated as transactions post) or periodic valuation (updated at period-end closing) | When does a receipt or a delivery change the inventory value in the ledger? |
| Costing method | Standard cost, FIFO or average cost — and whether the method can differ by product group | Value one item under our chosen method and show the journal entries. |
| COGS recognition | When cost of goods sold is recognized under your accounting standard and settings | Show COGS for one sale, from delivery to invoice. |
| Landed cost | Freight, duties, insurance and other charges included in inventory value | Add freight and duty to a receipt and show the updated product cost. |
| Cost variances | Differences between standard cost and actual purchase or production cost | Where do purchase price and production variances post? |
| Units of measure | Buying, stocking and selling in different units without valuation errors | Buy in cases, stock in units, sell in packs — show the cost per unit. |
| Period-end cut-off | Goods received but not invoiced, and shipped but not billed | Show how received-not-invoiced goods are accrued at month-end. |
| Reconciliation | Inventory value in operations agrees with the ledger | Reconcile the stock valuation report to the inventory account. |
Systems differ in exactly these details. In Odoo 20, for example, the Inventory app keeps a real-time stock valuation, while accounting inventory valuation is updated when bills or invoices are posted (perpetual, at invoicing) or through a stock-closing process (periodic, at closing). Odoo 20 supports Standard Price, FIFO and Average Cost (AVCO) costing methods, set for the company and adjustable by product category, and landed costs such as freight, insurance and customs duties can be included in product valuation.
Choose valuation settings deliberately with your accountants: they determine when expense is recognized and what the balance sheet shows between closes.
Month-end close, consolidation and reporting
Short answer
A new ERP should shorten the path from transaction to trusted report. Verify each step of your close on the candidate system — and treat multi-company and consolidation as requirements only if your structure needs them.
- Subledgers post to the general ledger without re-keying: sales, purchasing, inventory and payroll interfaces.
- Bank, receivables, payables and inventory reconcile in the system, with clear handling of unmatched items.
- Accruals, prepayments and period-end entries are prepared and reviewed in the system.
- Closed periods can be locked.
- Your management pack — profit and loss, balance sheet, cash flow, margin and aged balances — comes from system data, with drill-down to the source transactions.
- If you run more than one legal entity: inter-company transactions, currencies and consolidated reporting are demonstrated on your own structure.
For reference, Odoo 20 documents multi-company operation in one database, inter-company transactions that can generate counterpart orders and invoices, consolidation through account mapping and a consolidation ledger, multi-currency transactions, lock dates and an audit trail report. Whether these fit your entity structure and reporting obligations should still be demonstrated on your own scenarios.
How does your close compare?Check where your organization stands — take the 3-minute assessment
ERP implementation risk: early warnings and mitigations
Short answer
Much of an ERP project’s risk is visible early — in scope, ownership and data — and can be reduced before configuration starts. Ask every partner for a risk register before comparing proposals.
| Risk | Early warning | Mitigation |
|---|---|---|
| Scope | Requirements keep growing after the project starts | Agree process scope and decision criteria before selection; route changes through a change process |
| Ownership | No one can decide how a process should work | Name an owner for each core process before design begins |
| Data | Master data is duplicated, incomplete or inconsistent | Start cleansing early; migrate active records and validated opening balances |
| Customization | Legacy workflows are reproduced exactly | Prefer standard functionality; justify each customization by business value and upgrade cost |
| Integrations | Connected systems are discovered late | Inventory every integration, its owner and how failures are handled during planning |
| Testing (UAT) | Tests check screens rather than end-to-end scenarios | Test real scenarios, including exceptions and a full month-end close, with business sign-off |
| Cutover | No rehearsal; opening balances checked after go-live | Rehearse cutover and reconcile opening balances before switching |
| Adoption | Users keep spreadsheets alongside the new system | Train on real processes and retire parallel spreadsheets on a set date |
| After go-live | The project team leaves as issues appear | Agree post-go-live support, ownership and a stabilization period before go-live |
Where is your organization most exposed?Check where your organization stands — take the 3-minute assessment
Finance’s role across the ERP project
Short answer
Finance does not need to configure the system, but it should own the decisions that determine financial outcomes — and sign off before each stage moves on.
| Phase | Finance owns | Finance signs off |
|---|---|---|
| Selection | Business case, TCO model, financial decision criteria | The decision and the cost model behind it |
| Design | Chart of accounts, costing and valuation policy, approval limits, reporting requirements | Finance process designs and control design |
| Data | Chart of accounts mapping, opening balance approach, customer and vendor master data quality | Data quality and the migration approach for financial data |
| Testing (UAT) | Finance scenarios: order to cash, procure to pay, inventory valuation, month-end close | Test results for every finance scenario |
| Cutover | Opening balances, cut-off procedures, the first-close plan | Reconciled opening balances and go-live readiness |
| After go-live | First closes, reporting, control monitoring, the improvement backlog | The first month-end close on the new system |
For groups with several legal entities, add inter-company and consolidation scenarios to design, testing and cutover.
What to settle before implementation begins
Short answer
Settle scope, ownership, data, integrations, decision rights, leadership and success measures before configuration starts. Each is easier to decide now than to change once the project is under way.
- Scope: the processes, entities and locations in scope — and what is deliberately out.
- Process owners: a named owner for each core process, with authority to decide.
- Data: which records migrate, who cleans them and how opening balances will be validated.
- Integrations: every connected system, its owner and how failures will be handled.
- Decision rights: a steering group, who decides what, and how scope changes are approved.
- Internal leadership: a project lead with time allocated, and backfill where needed.
- Success measures: what must be true after go-live — for example the close timetable, reporting and control requirements.
LaunchMap is AAKoryx’s two-week pre-implementation engagement: executive workshops, business discovery and a roadmap that defines scope before build.Explore LaunchMap
Where Odoo fits — and where it may not
Our position
AAKoryx is an official Odoo Silver Partner. We believe Odoo deserves serious consideration when it fits the operation, and we say so. The framework in this guide applies whichever ERP you choose.
Odoo is a modular suite of business applications — including Accounting, Inventory, Purchase, Sales and Manufacturing — that run in one database. Inventory valuation entries are generated from stock and invoice activity rather than re-keyed between systems.
Odoo warrants evaluation when
- Finance relies on spreadsheets and re-keyed data to connect operations with the ledger.
- Sales, inventory, purchasing, production and accounting need to work from the same records.
- You want to add applications over time rather than buy one large system at once.
- You are prepared to adopt standard processes where they fit, and customize only where it adds real value.
Validate fit in more depth when
- Several legal entities, currencies or consolidation requirements are involved.
- Costing is complex — for example standard costing with significant variances, or landed costs across many suppliers.
- Industry-specific or regulatory reporting is required.
- Many integrations or high transaction volumes are expected.
Odoo may not be the right fit when
- Your industry requires certified, specialized functionality that standard Odoo and its ecosystem do not provide, and that would have to be built and maintained as custom code.
- The organization expects to reproduce every existing workflow exactly through customization rather than adopt standard processes.
- Your need is a narrow, specialized system, and integrated operations are not a goal.
- The organization cannot commit internal ownership and leadership to an implementation — a limitation for any ERP, not only Odoo.
Evaluating Odoo specifically?Evaluate Odoo against your operation
CFO ERP assessment
Where does your organization stand?
Answer nine short questions about your current systems and readiness. You’ll see your result immediately — no contact details needed.
FAQ
Frequently asked questions
- What should a CFO evaluate when selecting an ERP?
- Seven things, in order: the business case, process scope and ownership, decision criteria, multi-year total cost of ownership, fit on your own scenarios, implementation risk, and how the decision and later scope changes will be governed.
- What belongs in ERP total cost of ownership?
- Licences or subscription, hosting, implementation, data migration, integrations, customization, your own team’s time, training, support and upgrades over a multi-year horizon — compared with the cost of today’s manual workarounds.
- How should ERP platforms be compared beyond licence price?
- On how they behave over the system’s life: how pricing changes with growth, how implementation and upgrades work, what needs custom code, how integrations are maintained, whether data can be exported, and whether controls and reporting work on your own scenarios.
- What financial controls should an ERP support?
- Role-based access, segregation of duties, approval workflows, an audit trail of changes, period locking, reconciliation, and multi-company and multi-currency handling where your structure needs them — each demonstrated on your own scenarios.
- What should finance evaluate around inventory valuation and COGS?
- When stock movements become accounting entries (perpetual or periodic), the costing method, when cost of goods sold is recognized, how landed costs and variances are handled, units of measure, period-end cut-off, and how inventory reconciles to the ledger.
- What is finance’s role in ERP testing and cutover?
- Finance should run and sign off its own scenarios in user acceptance testing — order to cash, procure to pay, inventory valuation and a full month-end close — and approve reconciled opening balances before go-live.
- When should a company consider Odoo?
- When sales, inventory, purchasing, production and accounting need to work from the same records, when spreadsheets and re-keyed data connect the business today, and when the organization is willing to adopt standard processes where they fit.
- When might Odoo not fit?
- When certified, specialized industry functionality is required that standard Odoo and its ecosystem do not provide, when every existing workflow must be reproduced through customization, or when the need is a narrow specialized system rather than integrated operations.
- What is AAKoryx’s position as an Odoo partner?
- AAKoryx is an official Odoo Silver Partner. We are not neutral about Odoo and say so; the framework in this guide applies to any ERP decision, and we state where Odoo may not be the right fit.