Agricultural businesses can look simple from the outside.
A farmer grows a crop. The produce is harvested, processed, packaged, and sold.
But once an agricultural business operates at scale, the process becomes considerably more complicated.
There may be hundreds of farmers, multiple regions, crop cycles, planting inputs, quality inspections, warehouses, production stages, customer-specific product variants, sales orders, and export requirements.
Meru Greens Horticulture in Kenya provides an interesting real-world example of how these processes can be connected through an ERP system.
In a 2019 customer case study published by Frappe, Meru Greens' ERPNext implementation is described as a way to bring agriculture, supply chain, manufacturing, quality control, sales, inventory, accounting, and HR processes into a more integrated system.
The implementation was carried out by Navari, an ERPNext partner in Kenya.
Meru Greens Horticulture operates across the agricultural supply chain, working with smallholder farmers to produce and market fruits and vegetables while also managing processing, packaging, quality control, inventory, and distribution.
Its implementation of ERPNext demonstrates how an open-source ERP can be configured and extended to support a business with a highly specialized operating model.
The Business
Meru Greens Horticulture is a private service provider established in 1996 in Kenya.
The company works with smallholder farmers to produce and market fruits and vegetables for domestic and export markets, with French beans being one of its key products.
Its operating model extends beyond simply purchasing agricultural produce.
The company organizes farmers by geographical regions and subregions. Staff work with farmers throughout the production cycle, including farmer recruitment, land evaluation, soil and plant analysis, crop-cycle management, and the provision of agricultural inputs.
Once harvested produce reaches the company's processing operation, it moves through several manufacturing and quality-control stages.
The processing workflow includes activities such as:
- Receiving produce
- Inspection
- Washing
- Snipping
- Blanching
- Canning
- Sterilization
- Labelling and barcoding
- Packing
- Storage
- Shipment
The company therefore operates across multiple connected domains:
Smallholder Farmers
|
v
Agricultural Planning
|
v
Inputs Supplied to Farmers
|
v
Crop Production
|
v
Harvest Collection
|
v
Quality Inspection
|
v
Food Processing
|
v
Packaging
|
v
Inventory
|
v
Customer Orders
|
v
Distribution
This type of operation requires considerably more than a basic accounting system.
The Operational Challenge
Before implementing ERPNext, Meru Greens was dealing with several operational limitations in its existing systems.
Farmer information was not centralized, making it difficult to maintain a complete view of the company's farmer network.
There was also no centralized system for managing agricultural inputs advanced to farmers.
Crop-cycle information was not adequately digitized, while manufacturing and quality-control activities were not integrated into a single operational system.
The company also faced challenges managing multiple products, reconciling inventory, auditing stock, and producing real-time reports.
These problems are common in businesses that grow organically.
A company may initially create separate systems for accounting, procurement, inventory, manufacturing, HR, and field operations because each department has an immediate need.
Over time, however, those systems can create information silos.
The problem is not necessarily that each individual system is incapable of doing its job.
The problem is that the business itself does not operate in isolated departments.
For Meru Greens, a farmer could be connected to agricultural inputs, crop cycles, harvested produce, purchasing, inventory, and sales.
Manufacturing could depend on customer orders.
Inventory could depend on both purchasing and production.
Quality control could be connected to manufacturing operations.
The ERP therefore needed to represent these relationships rather than simply automate individual departments.
Why ERPNext?
Meru Greens selected ERPNext as the foundation for its business system.
One important characteristic of ERPNext is its ability to combine standard ERP functionality with configuration and customization.
Instead of building a completely independent application for every business process, the implementation could start with existing ERP capabilities and extend them where the company's processes required additional behavior.
The implementation covered several functional areas, including:
- Accounting
- Stock
- Buying
- Agriculture
- Manufacturing
- Selling
- Human Resources
This created a common platform across operational areas that had previously been fragmented.
The distinction is important.
An ERP implementation does not necessarily require every business process to be redesigned around the software.
A better approach is often to determine which existing ERP capabilities already match the business and then identify the specific areas where configuration or customization is justified.
Meru Greens' implementation followed that principle.
Mapping the Business to the ERP
One of the most interesting aspects of the implementation was how the company modeled its farmer relationships.
A farmer could effectively play two roles in the business.
As a supplier, the farmer provided agricultural produce to Meru Greens.
At the same time, the farmer could receive agricultural inputs from the company.
This meant that treating the farmer as only a conventional supplier would not accurately represent the business relationship.
The implementation therefore used the ERP to represent the farmer as a master entity with both supplier and customer relationships.
A custom script could automatically create the corresponding customer record when a farmer was created as a supplier of the farmer type.
This created a connected relationship between the two sides of the farmer's interaction with the business.
FARMER
|
+----------+----------+
| |
v v
SUPPLIER CUSTOMER
| |
| |
Provides Produce Receives Inputs
| |
+----------+----------+
|
v
ERPNext Records
This is a good example of where ERP implementation becomes business modeling.
The software is not merely storing contact information.
It is representing an actual commercial relationship.
Connecting Farmer Recruitment to Crop Cycles
The farmer lifecycle was also connected to agricultural operations.
Farmer recruitment involved activities such as checklists, land evaluation, and crop-cycle planning.
Rather than maintaining these activities as disconnected records, the implementation connected them to the broader agricultural process.
Custom fields were also introduced to capture information associated with different planting-order scenarios.
This allowed the organization to use the ERP's existing sales process while adapting it to its agricultural workflow.
The normal transaction flow could remain familiar:
Sales Order
|
v
Delivery Note
|
v
Sales Invoice
Instead of building an entirely separate transaction system for agricultural operations, the implementation extended an existing ERP process.
That approach has an important architectural advantage.
When customization is built around established ERP processes, businesses can preserve standard reporting, workflows, and transaction relationships while still supporting specialized requirements.
Managing Agricultural Products and Variants
French beans were not treated as a single undifferentiated product.
Meru Greens handled multiple varieties, including:
- Tiezo
- Goal
- Sagana
- Source
- Hawai
- Samantha
- Goldplay
These product variations could be represented through the ERP's item structure.
The item master could hold information such as:
- Lead time
- Reorder quantity
- Pricing
- Bill of Materials
- Product characteristics
This connected the product master to purchasing, inventory, manufacturing, and sales.
The value of this approach is not simply better product naming.
A properly structured product master becomes a foundation for downstream business processes.
PRODUCT MASTER
|
+-------------+-------------+
| | |
v v v
Buying Inventory Selling
|
v
Manufacturing
|
v
Reporting
When the same underlying product information is used across departments, the organization reduces the need to maintain duplicate product records in separate systems.
Connecting Field Operations to the Supply Chain
The company's supply chain also required coordination between its field operations and central operations.
Agricultural inputs were supplied to farmers, while harvested produce moved in the opposite direction.
Field officers worked across different regions and subregions and could use mobile devices during field activities.
Farmer categorization by region and type also supported operational analysis.
This created a more connected supply-chain model:
MERU GREENS
|
+---------+---------+
| |
v v
Agricultural Inputs Farmer Network
| |
v v
Farmers ----------> Harvest
|
v
Processing Plant
|
v
Manufacturing
|
v
Quality Control
|
v
Storage
|
v
Distribution
The ERP became a shared information layer between field operations and processing operations.
That is particularly important in agricultural businesses because supply does not originate inside a conventional warehouse.
It begins in farms.
Manufacturing and Quality Control
Manufacturing was another major component of the implementation.
Meru Greens used Bills of Materials, operations, and workstations to represent its production processes.
The output from one manufacturing operation could become the input for the next operation.
This allowed the processing workflow to be represented as a sequence rather than as a collection of disconnected activities.
For example:
Raw Produce
|
v
Inspection
|
v
Washing
|
v
Snipping
|
v
Blanching
|
v
Canning
|
v
Sterilization
|
v
Labelling
|
v
Packing
|
v
Finished Product
Production could also be driven by customer requirements.
A customer sales order generated from a blanket order could drive the production process.
Quality inspections were incorporated into items and Bills of Materials, helping connect manufacturing with quality assurance.
This matters because manufacturing and quality control are often treated as separate functions.
In a food-processing environment, however, quality is part of production.
An ERP system becomes more useful when those processes are represented as interconnected activities.
Inventory and Reporting
Inventory visibility was another important requirement.
The implementation used stock reports to provide information about warehouse inventory and stock movements.
Standard reports such as Stock Balance and Stock Summary provided operational visibility, while additional reports could be created using the Report Builder.
The system could also be configured to provide department-specific key performance indicators.
This illustrates an important ERP principle:
Reporting should emerge from operational transactions rather than being reconstructed manually afterward.
If purchasing, production, sales, inventory, and quality activities are captured in the same system, management can build reports around the underlying transactions.
Instead of asking several departments to prepare separate spreadsheets, the organization can use shared operational data.
HR and Payroll
The implementation also extended beyond agriculture, manufacturing, and inventory.
Human Resources functionality was included as part of the ERP system.
For Kenyan payroll requirements, salary components and salary structures were configured without requiring extensive additional customization.
Shift management was also configured for factory operations.
A custom payroll report was developed to support Kenya Revenue Authority tax-return requirements.
This is another example of the balance between configuration and customization.
Where the ERP already supported the required business process, configuration was sufficient.
Where a specific local reporting requirement was not adequately covered by standard functionality, customization filled the gap.
Configuration vs. Customization
One of the strongest lessons from the implementation is that not every business requirement needs custom software.
The implementation used several levels of adaptation.
Configuration
Configuration was used where existing ERP functionality could accommodate the business requirement.
Examples included:
- Salary components
- Salary structures
- Manufacturing operations
- Workstations
- Bills of Materials
- Quality inspections
- Stock reporting
- Department-specific KPIs
Custom Fields
Custom fields were introduced where additional business information needed to be captured.
Examples included:
- Farmer registration information
- Farmer recruitment information
- Planting-order-specific information
Custom Scripts
Custom scripting was used where the business needed behavior that standard configuration could not provide.
For example, when a farmer was created as a supplier, a script could automatically create the corresponding customer record.
A custom payroll report was also developed for local tax reporting requirements.
The broader implementation strategy can therefore be represented as:
Business Requirement
|
v
Can Standard ERP Functionality Handle It?
|
+--+--+
| |
YES NO
| |
v v
Configure Customize
| |
+--+--+
|
v
Validated Business Process
This approach can reduce unnecessary customization while still allowing the ERP to accommodate specialized operations.
Implementation Approach
The implementation followed an Agile approach rather than attempting to transform the entire organization in one step.
The major stages included:
- Business-process mapping
- ERP configuration
- Data migration
- User training
- User Acceptance Testing
- Go-live
- Post-go-live support
Business-process mapping was particularly important because the objective was not simply to install software.
The team first needed to understand how the organization actually operated.
That included understanding relationships between farmers, field officers, procurement, inventory, manufacturing, sales, HR, and finance.
Data migration then provided a bridge between the existing environment and the new ERP system.
User training prepared employees to work with the new processes, while User Acceptance Testing provided an opportunity to validate the system before production use.
The implementation also involved a Project Champion within the customer organization.
This person acted as a stakeholder, project manager, and single point of contact while helping coordinate internal teams and change management.
That organizational role is easy to underestimate.
ERP projects change how employees create, access, approve, and use information.
Without internal ownership, even technically sound implementations can struggle to achieve adoption.
Change Management
Technology implementation and organizational change are closely connected.
For Meru Greens, introducing a unified ERP system meant changing how different teams interacted with business information.
Farmers, field officers, manufacturing staff, warehouse teams, sales personnel, finance staff, and management all became part of a more connected operational system.
Training therefore had to go beyond showing users which buttons to click.
Users needed to understand how their activities affected other parts of the organization.
For example:
Field Officer
|
v
Farmer Information
|
v
Agricultural Activity
|
v
Harvest
|
v
Inventory
|
v
Manufacturing
|
v
Customer Order
|
v
Distribution
When users understand these relationships, data quality becomes an organizational responsibility rather than simply an IT concern.
Business Impact
The implementation addressed several of the company's major operational challenges by bringing previously fragmented processes into a unified ERP environment.
The system provided a centralized structure for farmer information, agricultural activities, inputs, products, inventory, manufacturing, sales, HR, and financial processes.
It also enabled the organization to connect agricultural production with downstream processing and distribution.
Several operational capabilities became more integrated:
- Farmer management
- Agricultural planning
- Input management
- Crop-cycle activities
- Procurement
- Inventory
- Manufacturing
- Quality control
- Sales
- Distribution
- Human resources
- Payroll
- Reporting
The implementation therefore represented more than an accounting or inventory upgrade.
It created a shared operational platform for a business whose activities span agriculture, manufacturing, and distribution.
Importantly, the available case-study information does not provide a detailed before-and-after financial ROI calculation or specific percentage improvements in revenue, cost, or production efficiency.
That distinction matters when evaluating enterprise case studies.
A credible case study should not invent performance numbers simply to make the implementation appear more successful.
The more defensible conclusion is that ERPNext addressed identified operational gaps by centralizing data, connecting workflows, supporting manufacturing and agricultural processes, and providing a common platform for reporting and management.
Lessons for Other Businesses
Meru Greens offers several lessons for organizations evaluating ERP platforms.
1. Start with business processes, not software features
The first question should not be:
"Which ERP has the most features?"
A better question is:
"How does our business actually operate, and which system can represent those processes effectively?"
The difference is significant.
Feature lists are easy to compare.
Business processes are not.
2. Look for the right level of customization
Customization can be valuable when it solves a genuine business requirement.
But unnecessary customization can increase complexity and make future upgrades more difficult.
The better strategy is to use:
Standard Functionality
↓
Configuration
↓
Custom Fields
↓
Custom Logic
Only move further down the chain when the business requirement justifies it.
3. Treat master data as strategic infrastructure
Farmers, products, customers, suppliers, employees, warehouses, and other core entities form the foundation of an ERP system.
If those entities are poorly modeled, downstream processes will also suffer.
Meru Greens' treatment of farmers as connected supplier and customer entities demonstrates why master-data design deserves serious attention during implementation.
4. Integration matters more than isolated automation
Automating accounting while leaving manufacturing, inventory, procurement, and field operations disconnected does not necessarily solve the underlying problem.
Enterprise value comes from connecting processes.
For a business such as Meru Greens, the real workflow is closer to:
Farmer
↓
Agriculture
↓
Harvest
↓
Inventory
↓
Manufacturing
↓
Quality
↓
Sales
↓
Distribution
The ERP becomes valuable because these activities can exist within one operational model.
5. User adoption is part of implementation
ERP implementation is organizational change.
Training, internal ownership, user acceptance testing, communication, and post-go-live support should therefore be treated as core implementation activities rather than optional additions.
6. Open-source does not mean "no implementation cost"
An open-source ERP can provide flexibility and avoid some traditional licensing constraints, but organizations still need to account for implementation, configuration, customization, migration, infrastructure, training, support, security, and ongoing maintenance.
The economic question should therefore be based on total cost of ownership and business value, not simply software license fees.
Conclusion
The Meru Greens implementation demonstrates how ERP can become the operational backbone of a business whose processes cross multiple industries and departments.
The company needed to coordinate smallholder farmers, agricultural activities, inputs, harvesting, manufacturing, quality control, inventory, sales, distribution, HR, and finance.
Rather than treating each function as a separate application, the ERP implementation connected them through a common platform.
The most important lesson is not simply that ERPNext was used.
It is that the implementation started with the business model and then adapted the software around that model.
Standard ERP functionality was used where possible. Configuration handled many requirements. Custom fields and scripts were introduced where the business required additional capabilities.
That balance is fundamental to successful enterprise software implementation.
For organizations considering an open-source ERP or any other enterprise platform, the question should therefore extend beyond:
"Can this software do what we need?"
The more useful questions are:
- Can the platform represent our business processes?
- Can it connect our departments and operational data?
- Where can we use standard functionality?
- Where is configuration sufficient?
- Where is customization genuinely necessary?
- Can our users adopt the new workflows?
- Can the organization maintain the system as it grows?
- Does the overall solution produce enough business value to justify its total cost?
Those questions move ERP evaluation away from feature comparison and toward something more important: building an information system around the way the business actually works.
Source and Research Note
This analysis is based on the original Frappe customer success story:
"Alone we can do so little, together we can do so much" — Frappe, 15 October 2019.
You can find the full success story here
