Moqui ERP for Multi-Company and Multi-Location Operations

By Visvendra Singh, CEO & Founder, NOI Technologies

Moqui ERP for Multi-Company and Multi-Location Operations

Moqui ERP for Multi-Company and Multi-Location Operations

Adding another company or warehouse changes the structure of an ERP implementation.

The group has to establish which company owns the inventory, which facility can fulfill an order, who can access each subsidiary, and how intercompany activity reaches finance. Product information can remain consistent across the group, while prices, taxes, stock ownership, invoices, and ledger records stay connected to the appropriate legal entity.

Moqui ERP provides a framework and reusable business artifacts for building these relationships into an enterprise application. Moqui Framework supplies the application tools, while Mantle Business Artifacts provides data models and services for organizations, facilities, products, assets, orders, shipments, invoices, payments, and accounting.

This article examines how those components can support multi-company and multi-location operations. For a broader introduction, read What Is Moqui? Features, Benefits, and Open-Source ERP Use Cases.

Technical perspective: NOI Technologies is listed in the official Moqui Service Providers directory. The directory credits NOI with delivering enterprise solutions using the Moqui ecosystem across ERP, ecommerce, and education.

What Changes When Several Companies Share One ERP?

Consider a distribution group with a US company and a UK company. The US entity sells to customers in the United States and ships from New Jersey. The UK entity invoices customers in the United Kingdom and operates a warehouse in Birmingham.

Both companies sell the same cordless drill from a common catalog. Its manufacturer code, dimensions, weight, and technical specifications remain consistent. The selling price, tax treatment, inventory ownership, customer invoice, and accounting entries depend on the company handling the transaction.

Record or setting How it is handled
Product name and specifications Shared across the group
US selling price Managed by the US company
UK selling price Managed by the UK company
New Jersey inventory Recorded with its owner and facility
Birmingham inventory Recorded with its owner and facility
Customer invoice Issued by the selling legal entity
Tax and accounting configuration Maintained for each company and jurisdiction

This arrangement requires a shared operational foundation with clear company boundaries. Combining every record would expose one subsidiary to another subsidiary’s prices, transactions, and financial data. Maintaining separate copies of everything would create duplicate products, customers, and supplier records that eventually drift apart.

The data model has to support both shared and company-specific information.

How Moqui Organizes Companies, Facilities, Products, and Inventory

The Mantle Universal Data Model separates the records involved in an operation instead of placing company, warehouse, inventory, and financial details into one oversized object.

Its Party model represents people and organizations. Facility records describe operating locations. Product records hold the definition of an item, while Asset records track physical inventory. Orders, shipments, invoices, payments, and accounting transactions provide the commercial and financial trail.

Organizations and business relationships

Mantle uses Party records for individuals and organizations. Organization details extend the Party record, while Party Relationship records connect parent companies, subsidiaries, customers, suppliers, employees, and other participants.

In the distribution example, the parent company and its US and UK subsidiaries each have an organization record. Their relationships describe the corporate structure. During an intercompany sale, the UK subsidiary can also take the supplier role in a transaction with the US entity.

A business customer can keep one consistent identity while maintaining separate orders, credit terms, invoices, and account balances with each subsidiary. This reduces duplicate contact data without combining company-level transactions.

Developers can review the underlying concepts in the official Mantle Party documentation.

Warehouses and internal storage locations

The Facility model covers warehouses, offices, buildings, rooms, and other operating locations. A facility can sit inside a hierarchy through the parentFacilityId field.

Storage positions within a warehouse use Facility Location records. Mantle provides locator fields for the area, aisle, section, level, and position. The New Jersey distribution center can therefore contain receiving areas, reserve stock, forward-picking locations, packing stations, and a returns area within one facility structure.

Facility Party records connect people or organizations with a facility in a defined role. These relationships can identify the owner, manager, tenant, picker, or another responsible party without embedding all those responsibilities in the warehouse record.

The official Mantle Facility documentation provides the current field and relationship details.

Shared products and separately owned inventory

The Product record describes the item being bought, sold, stored, or manufactured. An Asset record represents physical inventory associated with that product.

Mantle inventory assets include fields for the product, owning party, facility, storage location, physical quantity, available quantity, inventory status, lot, serial number, and relevant dates.

Two batches of the same cordless drill can use one Product definition while retaining different owners, facilities, quantities, statuses, and receipt dates.

Product: Cordless Drill Owner: Northstar US LLC Facility: New Jersey Distribution Center Location: Aisle 04, Section B, Level 02 Quantity on Hand: 150 Available to Promise: 120 Status: Available

This structure also supports shared warehouses. A distribution center can store stock for several subsidiaries or clients while keeping availability and ownership clear for each asset record.

The relationship between Product and Asset records is documented in the official Mantle Product and Asset model.

Following a US Order Through Moqui ERP

Business team reviewing global company locations, warehouses, and operational data through Moqui ERP

A US customer places an order through the group’s American ecommerce store. Northstar US LLC accepts the order and becomes the selling organization.

The order records the customer, store, selling company, product, price, delivery address, shipping method, and payment details. Inventory services then search for an eligible asset owned by the US company or otherwise approved for its use.

The New Jersey warehouse has 150 units on hand, with 120 available after existing reservations. The system reserves the required quantity from that asset. Warehouse staff receive the fulfillment work for the relevant storage location.

Once the order is picked and packed, the outgoing shipment records the origin facility, packages, carrier service, destination, and issued inventory. Northstar US sends the customer invoice and receives payment. The resulting accounting records remain associated with the US entity.

The product definition stays consistent throughout the process. The order identifies the seller, the asset identifies the inventory owner, the shipment identifies the fulfilling facility, and the invoice identifies the company responsible for the customer transaction.

When Inventory Belongs to Another Company

Now assume the US company receives an order while the available stock belongs to the UK subsidiary.

The group must choose between an intercompany sale, cross-company fulfillment, and a transfer of ownership. Each route produces a different commercial and accounting trail.

Intercompany sale before fulfillment

The UK entity sells the inventory to the US entity. An internal sales order for the UK company corresponds with a purchase order for the US company. The transaction records the change in ownership, any physical movement, the intercompany invoice, and the appropriate accounting entries.

The US company can then fulfill the customer order using inventory it owns.

Cross-company fulfillment

Northstar US remains the customer-facing seller while the UK company ships the product. The records need to preserve the selling organization, asset owner, fulfilling facility, customer invoice, and internal charge between the companies.

This approach can reduce unnecessary stock movement, but it requires agreed rules for tax, transfer pricing, shipping costs, returns, and financial settlement.

Ownership transfer without physical movement

Inventory can change ownership while remaining in the same warehouse. The facility and storage location stay unchanged, while the asset ownership and associated financial records are updated through the approved transaction flow.

Recording these events through orders, shipments, invoices, and accounting entries gives finance and operations a traceable history. A stock adjustment alone would leave the commercial reason for the change undocumented.

Shared Product Data and Regional Commercial Rules

A common product catalog reduces duplicate work across subsidiaries. It also allows ecommerce channels, warehouse systems, and reporting tools to use consistent identifiers and technical information.

Commercial rules still vary by market.

Northstar US can price the drill in USD, calculate state sales tax through an external service, offer UPS or FedEx shipping, and connect with US payment and accounting platforms. Northstar UK can use GBP, VAT rules, UK carriers, local payment services, and separate financial mappings.

Mantle Product Price records support different currencies, price purposes, customers, suppliers, stores, quantities, and effective dates. Product Store records connect the selling environment with inventory facilities, shipping gateways, payment gateways, and tax configuration.

A US implementation commonly needs connections with Shopify, Amazon, EDI partners, Avalara or Vertex, banking services, and parcel carriers such as UPS, FedEx, or USPS. These are project-specific integrations rather than connectors included automatically with every Moqui deployment.

The same global product can therefore support different storefronts, price structures, fulfillment services, and financial processes without creating a separate product master for each country.

Access and Reporting Across Companies

A user’s company selection provides working context, while authorization and record filtering control what the user can retrieve or change.

Moqui Framework supports artifact-aware authorization for screens, transitions, services, and entities. It also supports record-level authorization and entity filter sets. Mantle’s organization-based filtering pattern uses the selected organization and the organizations available to the current user when applying query conditions.

activeOrgId: The organization currently selected by the user filterOrgIds: The organizations included in the user's authorized scope

A warehouse operator in New Jersey can receive, pick, and ship inventory from that facility. A US finance manager can review invoices, payments, and accounting records for Northstar US. A group controller can access approved records across both subsidiaries.

These restrictions must continue through exports, reports, APIs, scheduled jobs, saved searches, and direct service calls. Interface controls alone cannot provide complete data separation.

The official Moqui security documentation explains artifact authorization, record-level authorization, and entity filter sets in more detail.

Reporting uses the same company and facility context. A global inventory total becomes useful when the user can identify the owner, warehouse, status, reserved quantity, and available quantity behind it.

Management question Required context
How much inventory does the group hold? Product, owner, facility, status, and available quantity
Which entity generated the revenue? Selling organization, customer, store, and invoice
Which warehouse fulfilled an order? Facility, shipment, carrier, and order
How much activity occurred between subsidiaries? Originating entity, receiving entity, orders, invoices, and accounting entries
Where are fulfillment delays occurring? Facility, workflow status, order date, shipment date, and service level

Those dimensions need to exist in the transaction records before a dashboard is built. Reporting software cannot reliably recover company or ownership context that was never recorded.

One Environment or Separate Moqui Deployments?

A shared Moqui environment suits companies that use common products, customers, teams, workflows, or reports. It reduces duplicate data and makes group-level visibility easier to maintain.

Separate deployments provide stronger technical isolation. They are appropriate when entities have independent release schedules, different hosting regions, distinct technical teams, or strict data-separation requirements.

A hybrid architecture can centralize selected master data while keeping financial, regulated, or region-specific operations in separate environments.

Architecture Typical use Main design priority
Shared environment Closely connected companies with common operations Organization filtering and access control
Separate deployments Entities requiring stronger technical isolation Data synchronization and consolidated reporting
Hybrid architecture Groups sharing selected master data Clear ownership and synchronization rules

Deployment should reflect operational overlap, data residency, security requirements, integration volume, reporting needs, and release ownership.

Moqui ERP Compared With Packaged Multi-Company ERP

Moqui starts at a different layer from packaged ERP software.

Odoo 19 documents a multi-company model with shared and company-specific records, company-based access controls, aggregate reporting, and configurable intercompany transactions.

NetSuite OneWorld supports subsidiary hierarchies and cross-subsidiary fulfillment through Global Inventory Relationships. Oracle requires additional inventory and shipping features for that workflow and currently documents an incompatibility with NetSuite WMS Advanced.

Both products begin with an existing ERP application. The implementation team configures the company, accounting, inventory, and intercompany capabilities provided by the product.

Moqui Framework supplies the application foundation, and Mantle supplies reusable business entities and services. The development team then builds the required screens, services, integrations, permissions, and transaction logic.

Evaluation point Odoo or NetSuite OneWorld Moqui ERP
Starting point Packaged ERP application Application framework and reusable business artifacts
Company structure Configured within the product model Designed around the required operating model
Intercompany workflows Use supported product settings and transactions Implemented through project-specific services and rules
Data model changes Follow the product’s extension system Can extend Mantle or introduce application-specific entities
Engineering ownership Shared with the vendor and implementation partner Held primarily by the organization and development team

A packaged ERP is usually the practical choice when its existing multi-company model matches the business. A Moqui-based system deserves evaluation when ownership, fulfillment, access, or intercompany workflows require structural changes that the packaged configuration cannot represent reliably.

What NOI Technologies’ Moqui Experience Adds

NOI Technologies appears in the official Moqui Service Providers directory. Its listing states that the company has delivered more than five enterprise solutions using the Moqui ecosystem and provides design, implementation, and support services.

The official Moqui add-ons directory also lists Fulfillor, a Moqui-based warehouse and 3PL fulfillment platform. Its documented technology stack includes Moqui Framework, Mantle UDM and USL, SimpleScreens, PopCommerce, React applications, and REST APIs.

NOI’s warehouse experience also includes Fulfillment Plus. In an NOI Technologies project example, Fulfillment Plus is presented as a US fulfillment provider for which the company developed a customized warehouse platform around client separation, inventory ownership, billing, reporting, and integrations.

In education, NOI documents a Moqui ERP implementation for Vinci School covering online admissions, parent communication, HR, and payroll workflows.

NOI’s wider enterprise portfolio includes finance-related workflows, payment integrations, approvals, and operational reporting. Its strongest publicly documented Moqui examples currently come from warehouse, ecommerce, fulfillment, and education applications.

NOI Technologies has operated since 2016. The company states that it has completed more than 100 ERP and enterprise software projects, although that broader company figure should not be interpreted as the number of Moqui implementations.

This project history helps the team address practical questions that arise during multi-company ERP development: inventory ownership, organization-level access, warehouse routing, client separation, financial system responsibility, and the investigation of transactions that cross company boundaries.

Questions to Resolve Before Development

Discovery should produce direct decisions about ownership, access, and transaction flow. A list of desired ERP modules is not enough to design a multi-company system.

  1. Which legal entities will create orders, shipments, invoices, and accounting records?
  2. Which company owns the inventory held at each warehouse?
  3. Can one subsidiary reserve or sell inventory owned by another?
  4. Which product, customer, and supplier records will be shared?
  5. Which prices, taxes, accounts, and approvals remain company-specific?
  6. What documents are required for intercompany sales and stock movements?
  7. Which users require access to several organizations or facilities?
  8. Which reports need group totals and entity-level detail?
  9. Which regional systems require real-time or scheduled integration?
  10. Does any entity require separate hosting, databases, or release schedules?

The answers guide the data model, entity extensions, services, access filters, integrations, interfaces, and deployment architecture.

Is Moqui ERP Suitable for a Multi-Company Operation?

Moqui ERP suits organizations where the relationships between companies affect everyday orders, inventory, fulfillment, permissions, and financial activity.

It provides a useful foundation for groups that need shared master data, separately owned inventory, custom intercompany processes, several warehouses, regional integrations, or company-specific access rules.

The decision should reflect the gap between the operating model and the capabilities available in packaged software. Configuration is generally the better route when that gap is small. Custom development becomes easier to justify when the differences affect ownership, transaction flow, security, or the wider system architecture.

Frequently Asked Questions

Should subsidiaries share one Moqui database?

Companies with shared products, customers, operational teams, and reporting often benefit from one environment. Separate deployments are more appropriate when entities require independent releases, regional hosting, or strict technical isolation.

What happens when one company sells inventory owned by another?

The workflow must identify the selling company, inventory owner, fulfilling facility, customer invoice, and internal financial relationship. The required orders, shipments, invoices, and accounting entries depend on when ownership changes and how the group records intercompany activity.

Which Mantle components can be reused?

Party, facility, product, asset, order, shipment, invoice, payment, and accounting entities provide a substantial starting point. The implementation still needs organization-specific access filters, approval rules, regional integrations, and intercompany services.

Discuss Your Multi-Company Moqui ERP Requirements

NOI Technologies provides Moqui ERP development and consulting services for multi-entity ERP platforms, warehouse systems, ecommerce applications, education platforms, and other enterprise operations.

The team can review your company structure, inventory ownership, facilities, data boundaries, integrations, and intercompany processes before recommending an application and deployment architecture.

Schedule a Moqui ERP consultation with NOI Technologies.