I’m looking for advice from experienced Workday Financials / Accounting Center / Integration architects who have designed similar patterns.

We implemented Workday Accounting Center about two years ago as part of our migration from Oracle to Workday. One recurring use case for us is M&A integration.

When we acquire a company, we need to bring the acquired company's monthly trial balance into Workday Accounting Center on an ongoing basis. The source ERP varies by acquisition — it could be NetSuite, Oracle, Workday, or another ERP.

Our current pattern

Today, we use Workday Studio to:

• Pick up the trial balance file from an AWS location
• Transform and map the source data
• Map the acquired company's accounts and dimensions to our Workday accounting structure
• Send the resulting data through our Accounting Center process

The monthly trial balance volumes are generally not very large, and this is primarily a monthly finance-close process.

The pattern works, but because we need to repeat this for M&A integrations, we're looking at whether there is a simpler, more scalable, and faster-to-implement architecture.

What I'm trying to understand

If you were designing this solution today, would you still use Workday Studio for this type of use case?

Or would you consider other Workday-native patterns such as:

• Accounting Center / Prism ingestion directly
• EIB
• Workday Orchestrate
• REST/SOAP APIs
• A combination of these approaches
• Or an external integration platform with Accounting Center handling the downstream accounting transformation

I'm particularly interested in experiences where the source ERP varies from acquisition to acquisition, but the target Accounting Center model is relatively standardized.

The main drivers for us are:

1. Reducing development effort
2. Accelerating M&A integration timelines
3. Reducing custom Studio development and maintenance
4. Leveraging more of the native Accounting Center capabilities
5. Creating a repeatable integration pattern that can be reused across future acquisitions

For those who have implemented Accounting Center in similar scenarios:

What integration pattern would you recommend if you were starting from scratch today, and why?

Also interested in any lessons learned around file ingestion, account/worktag mapping, error handling, reconciliation, and monthly close processing.

Would especially appreciate perspectives from people who have implemented this at scale across multiple acquisitions.

Our organization has standardized on Zuora Revenue (RMS) for revenue recognition, while Workday serves as our ERP. We are a large enterprise software company that continues to grow through acquisitions.

One recurring challenge is onboarding acquired companies that have their own billing platforms. Today we support a mix of billing systems including Oracle ERP, Oracle NetSuite, Stripe, Workday, and several custom-built billing solutions. These acquired billing platforms typically remain operational for 4–5 years before they're migrated to our enterprise billing platform.

Every acquisition currently requires building a new integration into Zuora Revenue. While the business models are largely similar (subscription SaaS, software licensing, usage/consumption, and self-service offerings), the source schemas and billing implementations vary enough that each onboarding becomes a custom engineering effort.

Our objectives are:

• Reduce onboarding of a newly acquired billing system from several months to 2–4 weeks
• Eliminate manual revenue uploads currently performed by Finance
• Decouple billing systems from Zuora-specific integration logic
• Standardize revenue data across all acquired billing systems
• Build an architecture that scales as additional acquisitions occur

Acquired Billing Systems

(Oracle ERP, NetSuite, Stripe, Workday, Custom)

│

▼

Enterprise Data Lake

(existing enterprise platform)

│

▼

Canonical Revenue Model

(owned by the Finance Systems team)

│

▼

Standardized Zuora Adapter

(single reusable pipeline)

│

▼

Zuora Revenue (RMS)

│

▼

Workday ERP

A few additional details:

• The enterprise data lake already exists and is widely used for enterprise analytics, AI, and financial reporting.
• Revenue integrations run in batch, so real-time processing is not a requirement.
• The goal is to have each new billing system map only to the canonical model while keeping the downstream Zuora integration reusable.
• Ideally, onboarding a new billing system would rely primarily on configuration and metadata-driven mappings, minimizing custom development.

I'm interested in hearing from architects who have designed similar acquisition-driven finance or revenue integration platforms.

Specifically:

1. Does a canonical revenue model make sense in this scenario, or does it become another long-term system to maintain?
2. Would you place the canonical model inside the enterprise data lake, or would you implement it as a dedicated integration/service layer?
3. How would you design the mapping framework so that onboarding a new billing system is primarily configuration-driven rather than code-driven?
4. How would you handle schema evolution and source-system differences over a 4–5 year coexistence period?
5. If you've built a similar post-acquisition finance integration platform, what architectural decisions worked well, and what would you change if you were designing it again?