Finance & Infrastructure

Finance & Infrastructure is Phase 1 of the implementation, the first phase after discovery. Six to twelve weeks of focused work that establishes the financial foundation and the technology infrastructure on which everything else will run. Done well, this phase produces a working General Ledger, functioning Accounts Payable and Receivable, a clean chart of accounts, migrated historical data, and a deployed and tested technology platform, all ready for the operational phases that follow.

This document describes what gets done during Phase 1, who does what, the standard cadence of work week by week, and what “Phase 1 live” looks like at the end.

1. Phase 1 scope

What is in scope for Phase 1

Capability	What it means in practice
General Ledger	Chart of accounts designed and configured. Financial dimensions defined (farm, crop, season, cost center). Posting rules set up. The book where every transaction will land.
Accounts Payable	Vendor master, payment terms, approval workflows, three-way-match configuration, the AP cycle from invoice to payment.
Accounts Receivable	Customer master, credit limits, billing rules, the AR cycle from invoice to receipt. Initial customer balances migrated.
Data migration	Historical financial data from legacy systems: customer master, vendor master, item master, open AR and AP, trial balance, bank balances. Migrated, validated, reconciled.
Technical architecture	Cloud (or on-premise) environment provisioned. Networks, security, backup, disaster recovery all configured. Identity integration with the business’s enterprise directory.
Banking integration	The integration with the business’s primary bank, supporting payment file submission, bank-statement receipt, and reconciliation.
Period-end and reporting	The standard financial reports (trial balance, balance sheet, income statement, cash flow) configured. Period-close process designed and tested.

What is out of scope for Phase 1

• Farm operations: block setup, work orders, mobile-app rollout, irrigation, crop planning. All in Phase 2.
• Supply chain operations: warehouse operations, sales orders, dispatch, quality control, traceability. All in Phase 3.
• Grower management: grower onboarding, contracts, and settlements. Typically built in Phase 3 alongside the broader commercial layer.
• Advanced analytics and AI: the analytics platform is provisioned in Phase 1 but the rich operational analytics and AI capabilities are built up across all phases.
• Cost analysis and profitability reporting: the GL is configured to support agricultural dimensions, but the full crop-level costing and margin analysis is meaningful only once operational data is flowing in Phases 2 and 3.

2. The standard Phase 1 cadence

Weeks 1 to 2: Foundation and chart of accounts

• Folio3 work: kickoff meeting; review of discovery outputs; chart-of-accounts workshop facilitation; provisioning of the development environment; setting up the project management infrastructure (issue tracker, communication channels, document repository).
• Customer work: finance lead and CFO engagement in chart-of-accounts workshop; gathering of existing chart of accounts and trial balance; identification of financial dimensions to be used (farm, crop, season, cost center, business unit); appointment of super-users.
• Milestone: chart of accounts agreed and documented; development environment ready; team structure confirmed.

Weeks 3 to 4: Master data and core finance configuration

• Folio3 work: configuration of the General Ledger with the agreed chart of accounts and dimensions; configuration of AP and AR workflows; design of approval workflows for finance transactions; banking integration design.
• Customer work: vendor master and customer master extraction from existing systems; data cleansing (duplicate vendor records, outdated addresses, inactive customers); approval-policy review (who approves what, at what value).
• Milestone: GL configured with agreed structure; AP and AR workflows configured; banking integration architecture agreed; cleansed master data ready for migration.

Weeks 5 to 6: Data migration and integration build

• Folio3 work: data migration scripts built (customer, vendor, item, open AR, open AP, trial balance, bank balances); banking integration built and tested in sandbox; technical platform deployment progresses (cloud environment, networking, identity, backups).
• Customer work: review and approval of migrated data in test environments; identification of any data quality issues; IT involvement in the technical platform setup (identity integration, network access, security policy).
• Milestone: first end-to-end data migration into test environment completed and reviewed; banking integration tested with real test transactions; technical platform deployed in test environment.

Weeks 7 to 8: User acceptance testing

• Folio3 work: UAT scripts written; test data prepared; user training sessions delivered for super-users; defect resolution as testing progresses.
• Customer work: super-users execute UAT scripts covering AP, AR, GL, banking integration, reporting, and period close; defects logged and prioritised; signoff at end of UAT.
• Milestone: UAT completed; defects resolved or accepted; super-users confident in the system; signoff received from finance lead.

Weeks 9 to 10: End-user training and go-live preparation

• Folio3 work: end-user training delivered (often co-delivered with super-users); production environment provisioned and configured; final data migration into production environment in a cutover dress rehearsal; go-live plan finalised.
• Customer work: end-user training attended by finance team; cutover plan reviewed; final master data updates; communication of the go-live date to the broader organisation.
• Milestone: production environment ready; final cutover plan agreed; users trained; go-live ready.

Weeks 11 to 12: Go-live and hyper-care

• Folio3 work: production cutover execution (typically over a weekend); on-site or remote hyper-care support for the first weeks of live operation; rapid response to issues; daily check-ins with the business.
• Customer work: finance team using the live system for daily work; flagging issues to the Folio3 hyper-care team; first month-end close on the new system; signoff of Phase 1 completion.
• Milestone: Phase 1 live in production; first month-end close completed; signoff received.

3. Chart of accounts and dimensions

What makes an agriculture chart of accounts work

• Standard structure: the headline structure follows standard accounting practice: assets, liabilities, equity, revenue, cost of sales, operating expenses, finance, tax. No reinventing the basics.
• Agricultural depth where it matters: where agriculture-specific reporting is needed (cost of growing per crop, packhouse cost, grower payments), the chart of accounts has the structure to support it. Not too deep (which produces unmanageable account lists); deep enough to support the reporting.
• Heavy use of dimensions: most agricultural reporting is driven by dimensions (farm, crop, variety, season, cost center, block) rather than account-level detail. The chart of accounts stays relatively compact; dimensions provide the cuts.
• Multi-entity considerations: where the business has multiple legal entities, the chart is designed to support entity-level statutory reporting and group-level consolidation.
• Local statutory requirements: the chart respects the local accounting and tax requirements (mandated account structures in some countries, tax reporting categories, statutory disclosures).

Common dimensions used in agribusiness implementations

Capability	What it means in practice
Farm	The physical farm where activity occurs. Critical for multi-farm operations; even single-farm operations may use it for future-proofing.
Crop	The crop being grown. Drives crop-level cost and revenue reporting.
Variety	Within a crop, the variety. Important where varieties have different commercial economics.
Season	The growing season (typically a year, but can be longer for perennials or shorter for short-cycle crops). Drives season-over-season comparison.
Block	The specific block on a farm. The deepest commonly-used dimension; supports block-level profitability analysis.
Cost center	Functional cost centers (operations, packhouse, sales, administration, support functions). Drives functional cost reporting.
Business unit	Where the business is organised into reportable business units, the unit is a dimension.
Region or territory	For geographically distributed operations, a regional dimension supports regional reporting.
Channel	Sales channel (domestic wholesale, export, retail, direct, processing). Drives channel margin analysis.

4. Data migration

What gets migrated

• Customer master: name, address, contact, payment terms, credit limit, tax registration, banking. Inactive customers archived rather than imported clean.
• Vendor master: name, address, contact, payment terms, banking, tax registration, approval status.
• Item master: item code, description, unit of measure, category, default GL accounts. The full operational item master may not be needed in Phase 1; Phase 2 and Phase 3 will add operational items.
• Chart of accounts and trial balance: the opening balances by GL account and by dimension, agreed against the legacy system’s most recent close.
• Open AR: outstanding customer invoices with original date, amount, currency, customer, due date. Open balances must reconcile to the AR balance in the trial balance.
• Open AP: outstanding vendor invoices, similarly. Must reconcile to AP balance in the trial balance.
• Fixed asset register: the fixed asset register with cost, accumulated depreciation, net book value, useful life remaining. Reconciles to the relevant balance sheet accounts.
• Bank account balances: opening balances for each bank account, reconciled to the bank statement on the cutover date.

The migration approach

• Multiple migration cycles: the migration runs multiple times before cutover. A first cycle to find issues. A second cycle to validate fixes. A dress-rehearsal cycle close to cutover to validate the production process. The actual cutover cycle.
• Validation at every step: each migration step is validated: record counts in vs. records in source, total amounts in vs. source totals, key business rules respected. Discrepancies are investigated before proceeding.
• Reconciliation to source: post-migration, the migrated balances reconcile to the source-system balances. The reconciliation document is signed off by finance before go-live.
• Cutover at a clean point: cutover happens at a clean point (typically the start of a financial period or month-end), so the legacy system closes one period and the new system starts the next. Reduces the awkwardness of straddling systems.
• Legacy system retained read-only: the legacy system is kept available read-only for a defined period after cutover (typically 3 to 12 months), so historical lookups can be done without burdening the new system.

5. Technical architecture and platform

What the technical workstream covers

• Cloud environment provisioning: the enterprise cloud platform on which AgriERP will run, provisioned in the right region(s), with the right service tier, sized appropriately for the business’s scale and growth.
• Networking and connectivity: secure network connectivity between the cloud environment and the business’s existing sites and systems. Required bandwidth, redundancy, and reliability planned.
• Identity integration: AgriERP authenticates against the business’s enterprise identity provider, so users sign in with their existing credentials and identity governance practices apply.
• Security baseline: the security configuration: encryption at rest and in transit, role-based access control, audit logging, data classification, regulatory compliance posture.
• Backup and disaster recovery: the backup schedule, retention, and recovery objectives. Disaster-recovery setup, including geographic redundancy where applicable.
• Monitoring and alerting: the platform monitoring setup, with alerts to Folio3 service desk and the business’s IT team for relevant events.
• Banking integration platform: the BURQ middleware components needed for banking integration. Tested in non-production with the bank’s test endpoints before activation in production.

On-premise vs. cloud trade-offs covered earlier

The deployment model decision was made during Discovery. Phase 1 implements the decision: cloud environments provisioned, on-premise hardware ordered and installed, or hybrid configurations established.

6. Common risks and how they are managed

Capability	What it means in practice
Data quality in legacy systems	Mitigation: data cleansing starts in Discovery and continues throughout Phase 1. Multiple migration cycles surface issues early. Where data is irrecoverably bad, the implementation deals with it explicitly (e.g. abandoned customers archived rather than migrated).
Chart of accounts disagreements	Mitigation: the chart of accounts workshop is run with the right participants (CFO, finance team, operations leadership for the dimensional view). The output is documented and signed off before configuration begins.
Banking integration delays	Mitigation: banking integration is started early in Phase 1, not left to the end. Banks often have their own approval and testing cycles; starting late risks slipping go-live.
Approval-workflow design overruns	Mitigation: approval workflows are designed in a series of structured workshops, not by trying to anticipate every edge case upfront. Workflows can be refined post-go-live; perfection on day one is not the goal.
Finance team availability	Mitigation: the finance team’s availability is planned during Discovery. Backfill for routine work is arranged where possible, so the team can focus on the implementation.
Go-live timing	Mitigation: go-live is timed to a quiet period in the finance calendar where possible (not in the middle of year-end close, not during peak harvest billing). Where business reality requires going live during a busy period, additional hyper-care is planned.

Why Phase 1 has to be solidEvery subsequent phase will post transactions into the General Ledger, integrate with banking, use the chart of accounts, and rely on the technical platform. If Phase 1 is shaky, the foundation cracks under the weight of the operational phases.This is why Phase 1 is treated with the seriousness it deserves: clean data migration, agreed chart of accounts, validated banking integration, deployed platform, trained users. The discipline of getting Phase 1 right is what makes the implementation succeed end-to-end.

In summary

Phase 1, Finance & Infrastructure, runs 6 to 12 weeks and establishes the financial foundation and technology platform of the implementation. The General Ledger is configured with the right chart of accounts and dimensions. Accounts Payable and Accounts Receivable are set up with proper workflows and approvals. Master data is migrated from legacy systems, validated, and reconciled. The cloud or on-premise environment is provisioned with the right security, networking, identity, backup, and monitoring. The banking integration is built and tested. Finance users are trained, the system goes live, and the first month-end close is completed on AgriERP.

With Phase 1 live, the financial heart of the business is on AgriERP. Phase 2 then builds the farm and field operations on top of that foundation.