What It Takes to Run 15 Operational Companies on Acumatica

Running 15 companies in an ERP system can sound impressive without actually telling you much. Fifteen holding companies that mostly exist for financial reporting are one thing. Fifteen operational companies that buy inventory, manufacture products, sell to customers, sell to each other, operate in multiple countries, deal with multiple currencies, and have to produce locally acceptable documents are something else entirely.

That distinction is what makes Eastman Music Company’s Acumatica environment interesting. Ralph Torres, Eastman’s Vice President of Operations, is dealing with 15 operating entities spread across the United States, China, Canada, Europe, and Australia. Some manufacture musical instruments. Some distribute them. Some do both. And in many cases, one Eastman company manufactures a product, sells it to another Eastman company, and that company ultimately sells it to the outside world.

The central lesson is not really about having 15 companies. It is about deciding what should stay standardized across all of those companies and what has to remain flexible because each country, business unit, tax regime, manufacturing operation, or customer group is different.

That same decision turns out to affect almost everything else. It affects inventory IDs, reporting, intercompany transactions, tariffs, invoice formats, ERP tenant structure, forecasting, Power BI, Microsoft Fabric, and even how useful AI can be.

Fifteen Operational Companies Are Not Fifteen Ledgers

Tim kept coming back to the word operational for a reason. Eastman is not simply consolidating financial statements from 15 entities. These companies make and move physical products.

The footprint includes five factories in China across four locations, a clarinet manufacturing operation in Vancouver, multiple manufacturing facilities on the East Coast, distribution companies in the United States, the Netherlands, and Australia, a retail flute store in Australia, and manufacturing operations in Switzerland and France. The exact activity differs by company, but these are businesses that make, buy, carry, and sell inventory.

That creates a very different ERP problem from a company that is mostly tracking dollars. Manufacturing a trombone is not just posting a purchase and a sale. There are bills of material, subassemblies, screws, processes, and the steps required to turn pieces of metal into an instrument. Ralph described Eastman’s manufacturing as very much not light manufacturing.

That manufacturing requirement was one reason Eastman needed to move beyond Sage 100. Ralph said Sage Intacct was not considered a fit for them based on the guidance they received from their Sage support organization, especially because inventory and manufacturing were central requirements. Tim was careful not to turn that into a blanket criticism of Intacct. His point was narrower: an ERP product that works very well for a financial or project-oriented organization can be a different proposition when quantities, inventory, manufacturing, and physical movement become the center of the business.

Eastman also has financial-only entities in Acumatica. Ralph jokingly leaves some of those “rich people problems” to the CFO. But those entities are not what makes the environment hard.

The hard part is that a saxophone can be inventory in one company, a sale in another, a purchase in another, and eventually revenue from an outside customer. A manufacturing company can look like it had a fantastic year because it sold a lot to an affiliated distributor. But if the distributor is now sitting on a warehouse full of unsold inventory, the larger organization has not really achieved the same thing as selling those instruments to the market.

So the reporting problem becomes deceptively simple to state: how much did Eastman actually sell to the world, not just to itself?

The Most Important Standard May Be the Item ID

Ralph is very strict about one surprisingly ordinary thing: the stock inventory ID needs to be the same across the companies. That may sound like master-data housekeeping. In this environment, it is much more important than that.

When the factory’s student alto saxophone is the same item as the distributor’s student alto saxophone, data can move between companies without translation. A factory shipment can be exported from Acumatica, handed to another company, and turned into the purchasing side of the transaction using the same item identifiers.

That common item language also makes attributes much more useful. Eastman stores a lot of characteristics on stock items, including things needed for international trade and reporting. Ralph described using item attributes for HS codes and country-specific tariff classifications, along with other product characteristics that matter for import and export paperwork.

The basic HS classification is six digits, while countries can extend that classification for their own purposes. Ralph described the U.S. version as a 10-digit code and gave an example from the musical instrument world where different classifications can apply depending on the product.

Eastman does not try to turn Acumatica into the tariff authority. A customs broker handles the actual import filing and the applicable tariff calculations. The ERP’s job is to contain the product information cleanly enough that the broker can get the right data and Eastman can use the resulting costs inside its own operational decisions.

That distinction is important. The ERP does not have to perform every specialized function itself. But the underlying data needs to be clean enough that specialized services, spreadsheets, reports, and other systems can use it without everyone reinventing what the product is.

Standardize the Core, Localize the Edges

International ERP gets complicated very quickly once data leaves the screen and has to become a real-world document. Inside Acumatica, Ralph said much of the actual work can look very similar from country to country. The differences show up heavily in what goes in and out.

China is a good example. Eastman’s Chinese companies use their own Acumatica tenant, including a Chinese language pack so users can work in Mandarin. They also need highly customized shipping and export documents because the regulatory requirements are different from what Eastman deals with in the United States.

Ralph described requirements around packing lists, currency records, government-required conversion information, permits, and export documentation. He also described a Chinese import/export arrangement where certain products can come in without tariffs if they are exported back out within a required time and the proper permit process is followed.

Acumatica did not simply arrive with every one of those country-specific forms ready to go. Eastman worked with a partner in Taiwan, introduced through its VAR, that also handles the Chinese language pack. That partner customized a large number of shipment documents so the Chinese operations could generate the forms they actually need.

The same pattern shows up elsewhere, just with different rules. Australia has GST. Europe has VAT. Canada can involve national and provincial taxation. Banking information changes by entity. Customers in different countries expect different information on invoices and purchase orders.

Even the idea of a customer-friendly price changes. In the United States, a retail price is normally thought of before sales tax. Ralph pointed out that in Australia, the customer expects the displayed price to include GST. If the target price is $1,000, the tax has to be backed into that $1,000 rather than added afterward.

So Eastman has different invoice forms for different regions. Report Designer handles much of that, including expressions that can change information such as the bank account based on the selling branch. Business Events can also help automate which form a newly created customer should receive.

Tim described these details as a kind of death by a thousand digital paper cuts. None of them individually sounds like an ERP strategy problem. But there are a lot of them, and every country has its own set.

Ralph’s approach is refreshingly practical. He asks the local employees to show him what an invoice should look like, then works with the VAR to figure out how to make Acumatica produce it. The local operation defines what “right” looks like. The ERP team figures out how to get there.

Separate Tenants Were a Specific Decision, Not a Universal Rule

Eastman currently uses separate Acumatica tenants for the United States, China, and the other international companies. A separate tenant is effectively a separate Acumatica application environment, so this is a meaningful architectural decision.

But Ralph did not present that structure as some universal best practice. In fact, he was explicit that the original decision was driven by the state of Acumatica at the time.

When Eastman was implementing Acumatica, multi-base-currency support was relatively new. Ralph said manufacturing was not yet something they felt was guaranteed to work safely with that capability. The U.S. companies were all in U.S. dollars, so keeping them together simplified that issue. The international companies were added separately as multi-base-currency capabilities matured.

In hindsight, Ralph said he might have put more companies in the same tenant if he were starting with the product as it exists now. China is the likely exception because the language configuration and highly specialized export documents create a good reason to isolate that environment.

There is also an unexpected benefit to the structure they ended up with. The U.S. tenant does not need to carry all of the international document logic. U.S. customers can get a common invoice, with Report Designer expressions handling branch-specific details such as banking information. The more complicated international logic stays where it belongs.

That is a good example of the broader theme. The question is not, “How many tenants should a 15-company ERP have?” The useful question is, “Which differences are significant enough that separating them makes the overall system easier to operate?”

Why Acumatica Won Over Business Central

Eastman made the decision to go with Acumatica in 2022, before all 15 of today’s operating companies were even in the picture. Ralph said the comparison came down to Acumatica and Microsoft Dynamics 365 Business Central, with additional companies added to the environment after the original go-live.

What is interesting is that Eastman was already very much a Microsoft company. They use Outlook, Excel, and the broader Microsoft environment extensively. So this was not a case where Ralph disliked Microsoft or wanted to avoid the ecosystem.

One factor was simply the difference in corporate focus. Ralph’s thinking was that Microsoft is a giant company with many products, while Acumatica’s entire business depends on the ERP product succeeding. He described that as more of a company-relationship and gut-feeling consideration than a claim that Business Central could not perform a particular function.

The pricing model was another major factor. Acumatica’s usage-based approach meant Ralph did not have to keep a per-user license count in the back of his mind while deciding who should get access. If another employee could get value from the ERP, the question did not immediately become whether that person was worth another named-user license.

Tim thought that behavioral effect was probably as important as the arithmetic. He would still be curious to take Eastman’s current annual Acumatica cost, divide it by the number of people who actually logged in recently, and compare the effective monthly per-user number with Business Central. Ralph had not done that analysis, although his rough sense was that Eastman would still be comfortable with the decision.

Ralph also mentioned reporting and other functional considerations, but he did not present the selection as a feature-by-feature victory lap. The interesting part was fit: ERP-company focus, the licensing model, manufacturing requirements, and the ability to scale access as Eastman expanded internationally.

AI probably would not have changed that decision in 2022, and Ralph was not sure it would change it today. Microsoft’s Copilot integration is interesting, but Eastman has already found that moving Acumatica data through Generic Inquiries, Velixo, OData, and Microsoft’s other tools does not create much of a barrier.

Excel Is Sometimes Perfectly Good Middleware

The conversation also produced one of those ERP ideas that sounds almost too simple: “Excel it out” and “Excel it in.” Eastman uses Excel as a practical handoff mechanism between companies and tenants.

A factory can send an invoice, Eastman can export the related shipment data, and that data can become the purchase order on the other side. Because the inventory IDs are standardized, the handoff is much easier than it would be if every entity had its own product coding scheme.

This is not necessarily a permanent manual process. Ralph’s progression is basically: if the handoff is occasional, use the export/import capability. If it becomes repetitive, build a Generic Inquiry and use an import scenario or Velixo write-back so the user is mostly moving data with a few button clicks.

That is a much more useful automation philosophy than automating something merely because an API exists. Start with the real workflow. Standardize the data. Make the manual transfer simple. Then automate the repetitive part once the process is understood.

Velixo fits nicely into that middle ground. Eastman uses it both for reporting and for writing data back into Acumatica. The accounting team in China uses it as well, inside the same Microsoft environment as the rest of the company.

Tariffs Made Landed Cost Matter in a New Way

For years, landed cost was not one of Eastman’s biggest operational concerns. That sounds strange for an international product company until Ralph explains why.

Eastman often buys from itself, and many outside purchases are highly specialized. If the company needs a particular tonewood or a gold flute tube, there may not be a meaningful vendor-shopping exercise where landed cost determines whether to buy from Supplier A or Supplier B.

Freight still mattered, of course, but it did not necessarily change the sourcing decision. So tariffs and freight could be treated more as a financial cost to manage than as a product-level number that radically changed the commercial decision.

Then tariff percentages became large enough that the old treatment stopped being useful. Ralph described moving from an older 10% to 15% concern into stacked tariffs that at times became dramatically larger, even citing a 125% example. At the time of the discussion, he said some products were landing in roughly the 20% to 50% range. At those levels, the effect can materially change margin.

That changed the question from “How much tariff expense did we have?” to “What does this specific piece of inventory really cost us?” Eastman began using landed cost transactions so the tariff could be assigned to the inventory carrying value.

The workflow combines several pieces. Eastman receives the entry summary showing what was imported and the total tariff bill. The team pulls the purchase order into Velixo, assigns the appropriate values, and writes the landed-cost transaction back into Acumatica.

Ralph used a deliberately rough saxophone example to illustrate it. If the internal purchase price were $500 and the tariff were 30%, the real carrying cost would be closer to $650. He corrected his own math mid-example, which actually made the point better: the exact sample number did not matter nearly as much as the fact that a large tariff can make the purchase price a misleading basis for pricing decisions.

That matters when product managers are setting prices or deciding whether to run a promotion. Something that looked like it had a 40% margin based on purchase price may not have anything close to that margin once the current tariff burden is included.

There is another wrinkle: the landed cost itself can already be stale. Tariff rates can change after the last purchase. Eastman therefore uses a Generic Inquiry that shows the latest landed cost and latest tariff-related information so the sales team has a better basis for thinking about future pricing, even if the data is necessarily time delayed.

Old inventory can also behave differently from new inventory. Dead stock purchased before a tariff increase may be sellable at a lower price than replacement inventory. So the timing of when inventory entered the country becomes part of the pricing decision.

That is when an accounting detail becomes an operating variable. Once tariffs are large enough, landed cost affects promotions, future pricing, margin analysis, inventory valuation, and even whether Eastman wants a factory to accelerate a shipment before a possible tariff change.

Intercompany Business Makes Ordinary Numbers Weird

Owning both sides of a transaction creates flexibility, but it also creates some very strange reporting problems. Ralph called it a blessing and a curse.

Eastman can decide when one affiliated company pays another, within the boundaries required to keep the companies healthy and the transactions appropriate. Internal payment terms therefore do not behave exactly like third-party customer terms.

The curse is reconciliation. With many companies buying and selling to each other, the organization can end up with a large number of intercompany AR and AP relationships. If one side records something differently from the other side, somebody has to find the mismatch.

Ralph estimated that the possible reconciliation groups are approaching 100. Most of that interconnected due-to/due-from activity is managed by the central accounting team in Pomona, with China handling some of its own accounting locally.

This is exactly the kind of work that theoretically can be done and practically often is not. There are too many relationships, too many rows, and not enough time for people to investigate all of them at the same level of detail.

AI Is Useful When It Can Attack Work That Was Barely Getting Done

This is where the episode’s ERP story turns into an AI story without really changing subjects. Eastman is getting useful AI results because the ERP data is already structured enough to hand to another tool.

For intercompany reconciliation, Eastman can use a Velixo report to pull Open AR and Open AP data with fields that should match. Instead of having someone build XLOOKUPs and manually hunt for differences, the team can give that data to Microsoft Copilot and ask it to analyze the mismatches.

Ralph described the result as a report that can quickly separate what looks good from what needs attention. Over time, the prompt can be refined so the accounting team gets a red, yellow, and green style view of the problems worth investigating.

The important part is that AI does not have to be perfect to create value here. Tim latched onto this because the alternative was not a flawless human process. In many cases, the alternative was that nobody had time to perform the analysis at all.

So “Is the AI 100% correct?” is probably the wrong first question. The human is still going to review the output. The more practical comparison is between having a reasonably good first-pass analysis and having no analysis because the work never made it to the top of the list.

Ralph connects this to the 80/20 rule. AI can filter out the mass of ordinary data and point a person toward the smaller set of transactions, products, or relationships that deserve attention.

Eastman has tried the same idea in production planning. They can give AI information about internal demand, outside customers, and production constraints and ask it to suggest a daily production schedule for the next couple of months.

The first answer does not become the production schedule just because an LLM produced it. Ralph described reviewing the result, changing it, asking why the model made certain decisions, and then improving the prompt so the next run avoids choices the team considers bad.

That is a very different use of AI from asking for a generic executive summary. It is closer to giving an analyst a first assignment, reviewing the work, and teaching the analyst what matters in this specific business.

Why Eastman Chose Copilot for This Work

Eastman made a deliberate choice to keep this work inside Microsoft Copilot. Ralph was not arguing that everyone should use Copilot or trying to turn the discussion into a product pitch.

The reason is largely security and integration. Eastman worked with its IT support company to secure the Microsoft environment so sensitive company information stays within the controls they are already managing. They did not want employees casually dropping company financial data into whatever public AI tool happened to be convenient.

Copilot also has access to more than ERP exports. It can work with Eastman’s OneDrive, Teams, and Outlook environment. Ralph can ask where a project stands or where the latest update on a saxophone development project occurred, and Copilot can search across those Microsoft sources.

Tim’s reaction was that Microsoft may have an important position precisely because it does not have to own the best underlying LLM. The model itself is only one piece. Search, security, identity, file access, communication history, and the tooling that finds the relevant information may matter just as much.

For Eastman, that means Acumatica does not have to contain every AI capability either. Ralph can get data out of Acumatica through Generic Inquiries, OData, Excel, or Velixo, combine it with information that lives elsewhere, and then analyze it in Microsoft’s environment.

Attributes and Generic Inquiries Become a Business Vocabulary

One of the more interesting technical details is how much business meaning Eastman has built with Acumatica attributes and Generic Inquiries. The attributes do more than decorate the item master.

Eastman uses them to group products by brands, territories, and other classifications that matter to management. Item classes provide the overall product structure, but attributes let the company create additional groupings that reflect how people actually think about the business.

Ralph even connects this to his background as a musician. In his mind, the product structure is a little like score order: there is a hierarchy and a way that related things naturally group together. A brand such as Eastman Brass can include tubas, French horns, trumpets, and trombones even though the underlying item-class structure needs more detail.

Generic Inquiries then apply rules to turn raw ERP transactions into management concepts. One example is distinguishing whether a product sold by a company was manufactured by that same company or distributed for another Eastman entity.

A human looking at the transaction may know instantly which one it is. The question is how to tell the system. Ralph described using expressions in a GI so that the relationship between the manufacturing company and selling company determines whether the transaction is classified as manufactured or distributed for reporting purposes.

That kind of logic is important because a generic ERP cannot possibly arrive knowing every management definition that Eastman has invented for itself. The system provides the building blocks. The company still has to define what its own numbers mean.

Ralph also clarified that this custom GI logic is not replacing Acumatica’s native MRP or replenishment capabilities. Eastman still uses those tools. The manufactured-versus-distributed classification is primarily part of sales reporting, goal setting, and forecasting.

Monthly Reports Are Becoming AI Input, Not Just Human Output

Eastman already has a substantial reporting layer built with Velixo. Ralph showed a group of reports that are scheduled to run at the beginning of each month, with roughly 15 reports arriving automatically.

Those reports slice the same underlying business in different ways. Management can look at sales by company, brand, territory, product grouping, year-over-year performance, inventory, overstock, and dead stock.

The reports are generated as Excel files rather than PDFs because the data is still useful after the report is delivered. Ralph described them as running unattended from a cloud computer in the Microsoft environment.

Now Ralph can take those 10 or 15 reports and give them to Copilot with a saved prompt. The basic request is essentially: act like a vice president of operations preparing for an international meeting and identify the five things that deserve attention right now.

That use case is simple, but it is also very believable. Ralph is not going to read every cell in every report and remember all of the relationships. The product managers are not going to catch every cross-report signal either.

AI can do the first pass. It can point out a handful of anomalies or patterns. Ralph can then decide whether any of them are actually important.

In the future, even that step may become scheduled. If the same reports arrive every month and the same prompt is useful every month, there is no obvious reason a person should have to remember to drag the files into the analysis every time.

Fabric Is the Next Step for Intercompany Forecasting

The reporting problem gets even more interesting when Eastman looks forward instead of backward. Forecasting across affiliated companies is difficult because one company’s sales forecast can become another company’s production requirement and another company’s internal sales target.

Ralph gave a student trumpet example. Shires is a premium trombone manufacturer near Boston. Eastman’s Chinese factories can manufacture a student trumpet associated with that business, Pomona can distribute it, and other international Eastman companies can also sell it.

If Pomona expects to sell a certain amount next year, that demand has to flow backward through the chain. Existing inventory reduces what Pomona needs to buy. The remaining demand affects Shires. Shires’ needs then affect what the Chinese factory has to produce and sell internally.

Now imagine Europe suddenly increases its forecast. That change has to ripple backward through the other entities so the internal sales goals and manufacturing requirements still reconcile.

Historically, each company could submit a forecast and somebody would back into the related numbers. Then something would change, a new product would launch, or one company would update its expectations without every other company getting the message. Ralph described the unpleasant result: months later, he and the CFO could be asking why the intercompany sales goals no longer matched.

That is the first major use case Eastman is building in Microsoft Fabric. Generic Inquiry data is being pulled through OData or APIs into Fabric so the forecast relationships can be modeled more systematically.

Part of the motivation is scale. Ralph said some of their Power BI datasets were reaching the point where refreshes could time out. Once the conversation becomes “we need a data lake,” Fabric becomes a natural place to explore because that infrastructure is already part of the platform they are adopting.

Eastman is not building all of this with an internal IT department. Their long-time managed IT company, Modern IT, is helping with the infrastructure and bringing in specialists for AI and data work.

Clean ERP Data Matters More Than an ERP-Branded AI Button

One of Tim’s strongest takeaways was that Eastman’s approach changes the way he thinks about “AI inside the ERP.” The most useful AI may not need to live inside Acumatica at all.

If the business question requires ERP data, email, Teams conversations, files, forecasts, and other context, an assistant that only sees the ERP is starting with a handicap. That does not make Acumatica’s own AI work irrelevant. Workflow-level AI inside the ERP could still be very useful.

But the larger analytical problem often spans systems. Eastman’s architecture is basically saying: get the structured operational data out cleanly, combine it with the other information people actually use, and analyze it where the broader context is available.

That makes the boring ERP work more important, not less important. Common item IDs matter. Attributes matter. Clear GI logic matters. Consistent definitions of manufactured versus distributed matter. Knowing which company sold to which company matters.

AI cannot magically know Eastman’s business model just because it can read the transaction table. It still needs humans to define what a brand means, which internal sale should count in which analysis, when a tariff cost changes a pricing decision, and how a chain of intercompany forecasts should flow.

Ralph has noticed that Copilot seems to understand more of those relationships as the prompts and usage mature. But he still sees a human role in defining what the business means. That is probably the piece of the AI conversation that is easiest to underestimate.

The ERP Career Path Was Not an Accounting Path

There is a nice connection between this implementation style and Ralph’s own background. He did not come into ERP through accounting, finance, computer science, or IT.

He studied music performance at Cal State Northridge and Cal State San Bernardino and expected that performing jazz might require a practical day job. Eastman Strings happened to be hiring for customer service, which was close enough to music to make sense. He took the job.

More than 18 years later, he is Vice President of Operations. Along the way he worked as a product manager, helped develop Eastman’s saxophone line, and remained involved with the actual musical instruments the company sells.

Tim’s reaction was that this supposedly unusual route into ERP may actually be pretty normal. There really is not one obvious path into mid-market ERP because the job is not purely accounting and it is not purely programming.

Ralph thinks the music background helped. Music has an analytical side involving numbers, patterns, scales, and structure, but it also has a creative side. He sees ERP work the same way: understanding the tool matters, but so does figuring out how to connect departments, processes, and information that normally live in separate silos.

That may be the best description of what Eastman has actually done. The Acumatica environment is not impressive because somebody configured 15 company records. It is impressive because the team keeps finding practical ways to make the data connect across manufacturing, distribution, accounting, international compliance, reporting, and now AI.

The Practical AI Opportunity Is Already Here

Ralph’s closing AI advice was much less futuristic than most AI conversations. He thinks companies can get useful value right now with tools they already have.

Take an inventory balance, open sales orders, sales history, or another large operational dataset and ask AI what deserves attention. The answer is not automatically correct, and it is not supposed to replace the person responsible for the decision.

The value is that thousands of rows become a manageable list of things to investigate. A human is bad at staring at huge tables and spontaneously noticing the five odd numbers that matter. An LLM can help with that first pass.

Tim was completely sold on that framing. If a company already performs a careful analysis every week with a great human process, AI has to compete with that process. But if the analysis theoretically should happen and realistically almost never does, the bar is much lower.

Better-than-nothing analysis can be a big operational improvement. It can also put a fact in the back of someone’s mind so that, later in a meeting, another piece of information suddenly connects to it. Ralph said that has already happened to him a few times.

Bottom line, the interesting part of this story is not 15 companies or even AI. It is the data foundation underneath both of them.

Eastman standardized the things that needed to mean the same thing, especially product identity and the definitions used for reporting. It localized the things that genuinely differ, such as invoices, tax presentation, banking information, language, and regulatory documents. It used Excel and Velixo where those tools were practical, Acumatica Generic Inquiries where business rules needed to be expressed, and Fabric where the scale and cross-company forecasting problem started demanding something bigger.

Now AI has something useful to work with. Not because the ERP magically understands the business, but because people spent years teaching the systems what the business means.