Blog – DSD Business Systems

You’ve Heard a Lot About AI. Here’s What It Can Look Like in Sage 100

Tamara Nenninger — Wed, 10 Jun 2026 06:51:11 +0000

Artificial intelligence has been an ongoing business conversation. You have probably heard about AI assistants, predictive analytics, automation, and tools that promise to help people work faster. The challenge is understanding what those ideas actually mean for the systems your company already uses.

For Sage 100 customers, AI is starting to take a more practical form. Sage has introduced the Sage AI Help Agent, an in-product virtual assistant that helps users find answers to common questions while working in Sage 100. Users can search common topics or ask individual questions through a guided help experience in the Sage 100 Information Center. Each query is handled independently, making it best suited for quick, specific questions rather than extended back-and-forth conversations.

Sage AI Help Agent is an important step, but it is not the only way Sage 100 customers can bring smarter technology into their business. Independent software vendor solutions such as Phocas BI and ConverSight can further enhance Sage 100 by extending reporting, analytics, forecasting, planning, and access to business insights.

These solutions are not competitors to Sage 100 or replacements for Sage AI. They are complementary add-ons that help customers get more value from the Sage 100 platform they already use.

Sage AI Help Agent can help answer, How do I complete a specific task in Sage 100?”

Phocas BI can help answer, “What is happening in my business, and how is performance changing across key areas?”

ConverSight can help answer, “What trends, patterns, and forward-looking insights can AI identify to support decisions?”Together, these tools show what AI and intelligent technology can look like in a modern Sage 100 environment.

AI Is Becoming Practical for Sage 100 Users

AI can sound like a major technology initiative that requires replacing software, rebuilding business processes, or hiring a team of data scientists. For Sage 100 customers, that does not have to be the case.

AI adoption can begin with practical tools that support the work your team already performs.

Sage describes Sage Ai as technology designed for finance and business that can automate routine tasks, identify errors, and uncover insights. The new Help Agent brings one part of that strategy directly into the Sage 100 user experience. (Sage)
Instead of requiring users to search across multiple resources, Sage AI Help Agent provides a dedicated place to ask common product questions. It can help users locate relevant information while they are working, making AI feel less abstract and more like a useful part of the everyday Sage 100 experience.

That is an important distinction. AI does not need to take over an entire process to be valuable. It can help reduce small delays, make information easier to find, and give employees a more intuitive way to interact with business software.

What Is Sage AI Help Agent?

Sage AI Help Agent is an AI-powered, product-specific assistant available through the Sage 100 Information Center. Sage describes it as an in-product virtual assistant that provides answers as users work in Sage 100. Users can search common topics or ask their own questions through chat.

The first version is available in English and is included with an eligible customer’s current subscription.

Sage 100 customers must be using version 2023.0 or newer to access the Help Agent.

Sage has also made the Help Agent available for eligible Sage 300 releases, including 2024.8, 2025.4, 2026.1 or newer. Sage 300 customers using the web UI must be on version 2025 or newer.

For current Sage 100 customers, the Help Agent provides a new way to approach familiar product questions. A user may need assistance locating a feature, reviewing a routine process, or finding the right help topic. Instead of relying immediately on another employee, the user can begin with Sage AI Help Agent.

This can be particularly useful for occasional processes, newer users, and employees who need a quick refresher.

What Sage AI Help Agent Does Not Replace

Sage AI Help Agent is a helpful addition to Sage 100, but it is important to understand its role.

It does not replace DSD support, professional consulting, formal training, or internal business procedures. It is also not intended to make accounting decisions, troubleshoot every technical issue, or determine how your company should configure a specialized workflow.

Questions involving data corrections, accounting treatment, integrations, customizations, security, system performance, or company-specific processes should still be directed to the appropriate internal expert or Sage 100 consultant.

The Help Agent is best viewed as a new first step for common product questions. It helps users find information faster while preserving the need for experienced guidance when an issue is more complex.

That balance is what makes the tool practical. Users receive more immediate assistance without losing access to the people and expertise needed for important business decisions.

Sage AI Is the Beginning of a Smarter Sage 100 Environment

Finding product answers faster is valuable, but it represents only one part of what intelligent technology can bring to Sage 100.

Your team may know how to enter transactions, process orders, manage inventory, and complete accounting tasks. The next challenge is understanding what all that activity means for the business.

Which products are producing the strongest margins?

Where is inventory moving more slowly than expected?

Which reports require too much manual preparation?

Which customers are changing their buying behavior?

How are actual results comparing with the budget?

Where could forecasting help the business prepare for future demand?

These questions move beyond product help. They require reporting, analytics, forecasting, and decision intelligence.

This is where Sage 100 add-ons such as Phocas BI and ConverSight can extend the AI and intelligence conversation.

How Phocas BI Enhances Sage 100

Phocas BI is a business intelligence and financial planning platform that integrates with Sage data. It helps businesses bring information from Sage ERP and other systems into a unified environment for reporting, analysis, and planning.

Phocas enables users to explore data through interactive dashboards, build financial reports, manage budgets and forecasts, and analyze performance across the organization. With built-in AI capabilities, users can also ask questions in natural language to quickly uncover insights about customers, products, sales, and operations.

The platform is designed to make data accessible to teams across finance, sales, inventory, purchasing, and leadership, without requiring advanced technical skills. It also provides transparency by showing how results are calculated, helping users trust and validate the answers they receive.

Rather than replacing Sage 100, Phocas extends it by adding a flexible analytics and planning layer that helps organizations better understand and act on their data.

What Phocas BI Can Add to the Sage 100 Experience

Sage AI Help Agent improves access to product guidance. Phocas BI improves access to business information. That can include:

Interactive dashboards built from Sage 100 data

Margin and profitability analysis

Financial reporting with drill-down capabilities

Executive and departmental performance reporting

Sales analysis by customer, product, salesperson, branch, or territory

Inventory and purchasing visibility

Budgeting and forecasting

AI-powered natural language querying to ask questions and get immediate answers from your data

Phocas is especially relevant for Sage 100 customers who feel limited by static reports or spend too much time rebuilding information in spreadsheets.

It gives users a more flexible way to ask follow-up questions of the data. A manager can begin with a high-level result, identify an area that needs attention, and continue into more detailed information.

This supports a broader goal of business intelligence: helping people move from receiving reports to actively understanding performance.

How ConverSight Further Extends AI for Sage 100

ConverSight adds another dimension to the Sage 100 AI conversation.

ConverSight provides agentic AI, analytics, forecasting, and planning capabilities for Sage environments. Its Sage solution is designed to unify ERP data, automate reporting, support forecasting, and help users identify insights more quickly.

One of ConverSight’s central features is Athena, a conversational AI experience that allows users to ask questions about business data using natural language. ConverSight positions Athena as a way to understand KPI changes, examine trends, and support root-cause analysis without requiring users to build each report manually.

For Sage 100 customers, this can create a more conversational relationship with data.

Instead of beginning with a report layout, users can begin with a business question. They may want to understand why a metric changed, identify a developing inventory concern, review sales performance, or examine a forecast.

ConverSight can also support demand forecasting, inventory optimization, variance analysis, and planning. The company describes its Sage integration as an intelligence layer that works with Sage 100 and Sage 300 data across finance, sales, inventory, and supply chain use cases.

Like Phocas, ConverSight does not replace Sage 100. It enhances the Sage environment by adding tools for analytics, prediction, conversational data access, and AI-assisted decision support.

ConverSight supports AI-assisted analysis and planning

ConverSight adds conversational analytics, predictive insights, forecasting, inventory intelligence, and agentic AI capabilities to connected Sage data.

Each solution brings different strengths to the Sage 100 experience, with some overlap in analytics and forecasting capabilities. Phocas provides strong BI, financial reporting, and planning tools with intuitive dashboards and AI-assisted querying, while ConverSight emphasizes conversational analytics, automated insights, and advanced AI-driven analysis. The right fit depends on how your organization prefers to interact with data and the level of automation and AI-driven insight it needs.

What a Smarter Sage 100 Platform Can Look Like

A smarter Sage 100 environment does not need to look futuristic or unfamiliar. It can look like practical improvements across the organization.

These improvements all begin with the data and workflows your organization already has in Sage 100. The purpose of the add-ons is to make that foundation easier to use, understand, and act on.

It can mean sales leaders receiving clearer visibility into customer and product performance.

It can mean finance spending less time rebuilding reports.

It can mean users finding product guidance without leaving Sage 100.

It can mean inventory teams identifying demand changes and potential issues earlier.

It can mean leadership receiving more timely insight instead of waiting for another spreadsheet to be prepared.

AI in Sage 100 Is About Better Access to Answers

The larger AI conversation often focuses on dramatic predictions. For Sage 100 customers, the immediate opportunity is more practical.

AI and intelligent add-ons can make answers easier to access.

Phocas can make reporting and performance answers easier to explore.

Sage AI Help Agent can make product answers easier to find.

ConverSight can make analytical, predictive, and planning answers easier to uncover.

That is what AI can look like in your Sage 100 platform. It is not one tool trying to do everything. It is a connected set of capabilities that supports users, improves visibility, and helps the organization make better use of its business data.

Want to learn more about Sage 100?

Contact us or check out our resource center!

You’ve Heard a Lot About AI. Here’s What It Can Look Like in Sage 100

DSD Business Systems and Endpoint Automation Solutions Deepen Strategic Partnership to Advance Manufacturing Solutions for the Sage 100 Community

IN-SYNCH Marketplace Integration for Sage 100–More Than Just Amazon

Connector API for Sage 100 Makes Custom Solutions Possible

The post You’ve Heard a Lot About AI. Here’s What It Can Look Like in Sage 100 appeared first on DSD Business Systems.

Healthcare ERP Modernization: Building the Business Case for Your Board

DSD Business Systems — Fri, 05 Jun 2026 20:33:58 +0000

By the time ERP modernization reaches a board agenda, the work that determines whether it gets approved has already happened. The CFO has built the case. The CIO has built the case. The audit committee has heard the case. The board meeting is where it gets ratified.

The cases that get ratified share a structure. They lead with margin, not technology. They quantify risk in board-relevant terms. They present a defensible cost-benefit model with explicit assumptions. They explain what will actually be different in 18 months, and they connect that difference to the strategic priorities the board has already endorsed.

This is the framework for building that case. It is written for CFOs at mid-market health systems who are at the point of moving from internal alignment to board ratification. It assumes you have already done the diagnostic work: the maintenance burden audit, the five-year TCO model from SaaS vs. On-Premise ERP for Mid-Market Hospitals: A Rigorous TCO Comparison, and the year-by-year budget from What Healthcare Finance Teams Should Budget for in an ERP Migration. What follows is how to package that work for the board.

The Four Pillars of the Case

A board-ready business case for healthcare ERP modernization rests on four pillars. Each one should map to a strategic priority the board has already accepted. The pillars are margin improvement, risk reduction, IT capacity recapture, and audit and compliance efficiency.

Pillar 1: Margin Improvement Through Decision Velocity

Healthcare operating margins compressed materially through 2023 and 2024 and remain volatile across most mid-market health systems. In that environment, the value of faster, more accurate financial information is not theoretical. It is direct. A decision made in week one of a margin compression event mitigates damage. The same decision made in week six concedes it. The cost-of-status-quo framing developed earlier in this series, in The True Cost of “If It Ain’t Broke” ERP Thinking in Healthcare and Real-Time Financial Visibility: Why Healthcare CFOs Are Moving to Continuous Close, is the foundation this pillar builds on.

The board cares about this framing because it maps to enterprise strategy, not to IT.

Pillar 1 talking points for the board:

Close cycle compression. Current close averages 12 to 15 business days; modernization brings it to 5 to 7. The value is not the compression itself; it is the closing of the gap between operational reality and leadership visibility.
Continuous service-line profitability. Reporting that currently takes two weeks of manual rebuild after close becomes a continuous view. Capital allocation, payer contract negotiations, and service-line strategy get informed by data weeks earlier than the current state allows.
Real-time scenario modeling. Payer mix changes, Medicare rate adjustments, and labor cost shifts that currently require consultant engagement or weeks of internal effort can run against live data in minutes on an integrated planning platform.

Quantified margin impact. Modernization that delivers close compression alongside dimensional reporting can move margin meaningfully. For a mid-market health system, even a modest margin improvement on a hundred-million-dollar revenue base outweighs the platform investment over a reasonable horizon. Build your own payback math using your revenue and margin assumptions.

Pillar 2: Risk Reduction in Financial Reporting

Audit committees ask different questions than full boards do, and the modernization case has to satisfy both audiences. Risk reduction is where the audit committee case lands.

Legacy on-premise ERP environments in healthcare present several risk patterns the audit committee will recognize.

Single-person dependencies. The consolidation workpaper that only one staff member fully understands. The integration script that one IT engineer wrote five years ago and still maintains. The Medicare cost report build that lives in one consultant’s head. These dependencies are material weaknesses waiting for a departure event.
Manual control gaps. Flat-file integrations, manual journal entries for intercompany eliminations, and Excel-based consolidations create control gaps that internal audit and external audit both flag year after year. The cost of those gaps shows up in audit hours, in remediation efforts, and in occasional restatements that boards never want to discuss.
Audit trail reconstruction. When auditors request supporting detail, legacy platforms force the finance team to reconstruct the trail across multiple systems. That reconstruction time is billable. It is also where errors get discovered late.

Modernization addresses each of these patterns structurally, not procedurally. Native audit trails. Automated intercompany eliminations. System-managed segregation of duties. Continuous controls monitoring. The audit committee response to these capabilities is usually immediate and positive.

Pillar 2 talking points for the board:

Material weakness risk reduction. Manual consolidation workpapers and single-person dependencies are eliminated, addressing two of the most common findings in healthcare finance audits.
Lower external audit fees. Typical drop of 8 to 15 percent within two years of migration, driven by reduced support effort during fieldwork and cleaner audit trails.
Internal audit redirection. Capacity shifts toward higher-value activities (process audits, operational reviews, ERM) rather than supporting external audit cycles.
Stronger cybersecurity and operational posture. Vendor-managed infrastructure carries SOC 2 and HIPAA-aligned hosting certifications that internal IT teams cannot replicate at the same scale.

Pillar 3: IT Capacity Recapture

This is the pillar most often under-presented because finance teams own the modernization case and may not feel confident speaking to IT capacity in detail. Bring the CIO into the board presentation. The capacity argument deserves a direct voice.

The IT capacity argument is not about cutting IT cost. It is about redirecting IT capacity. Mid-market health systems consistently commit more IT capacity to legacy ERP maintenance than is visible in the project portfolio. None of those people get laid off after modernization. They get redirected to work the organization has been deferring.

Pillar 3 talking points for the board:

Current state. A meaningful share of IT capacity is committed to ERP maintenance, integration upkeep, and version management. Quantify your own number using the audit framework in our earlier post for CIOs.
Future state. That commitment drops materially on a modern platform, narrowing to configuration management and exception monitoring.
Net redirection. The recovered capacity becomes available for strategic work: cybersecurity hardening, EHR optimization, clinical systems work, patient-facing digital initiatives, and analytics maturity.

The dollar value of this redirection is meaningful even before strategic outcomes are quantified. Fully loaded IT capacity in healthcare is real money, and the strategic value of what those FTEs deliver compounds beyond the cost line itself. The finance-side proof point on the same dynamic is captured in 20+ Hours of Manual Imports, Gone: What the EHR-to-GL Workflow Looks Like After Cloud Migration, which describes the parallel recovery on the finance side of the house.

For boards focused on cybersecurity preparedness, which most healthcare boards now are after recent high-profile incidents in the sector, the capacity redirection toward cybersecurity is often the most resonant aspect of the case.

Pillar 4: Audit and Compliance Efficiency

Pillar 2 addressed the risk dimension of legacy systems. Pillar 4 addresses the operational efficiency of the compliance work itself: the recurring hours that finance teams spend supporting audits, regulatory reporting, and tax filings under the current platform.

Healthcare finance teams spend material time supporting external audits, internal audits, regulatory reporting (340B, Medicare cost reports, IRS Form 990 for nonprofit systems, state regulatory filings), and tax compliance. On legacy platforms, this work is heavily manual. On modern platforms with healthcare-validated reporting, much of it becomes report generation rather than report building. Sage Intacct‘s HFMA peer-reviewed reporting library is the specific reason this category compresses for most mid-market hospital finance teams after migration; the reports the regulators expect already exist on the platform.

Pillar 4 talking points for the board:

Medicare cost report. Preparation time drops materially when the GL is structured around healthcare-specific dimensions out of the box, rather than requiring custom report builds annually.
340B compliance reporting. Becomes report-driven rather than data-reconstruction-driven.
Tax filing support. Time reduces because tax-relevant data is captured systematically rather than reconstructed.
Regulatory response time. When a state regulator or CMS auditor requests specific data, the platform produces it. The current state often requires days of preparation by senior finance staff.

Across these compliance functions, mid-market health systems typically recapture a meaningful portion of finance staff time over the course of a year. This capacity also redirects rather than reduces, but the redirection is usually toward higher-value analytical work that strengthens strategic decision support.

Building the Board Outline

A board presentation of an ERP modernization case usually runs 8 to 12 slides. Here is a slide-by-slide outline that has held up across the implementations DSD has supported.

Slide 1: The strategic problem. Frames the current state. Margin compression, IT capacity constraint, audit committee feedback, board strategic priorities. No technology language yet.
Slide 2: Why now. The cost of inertia. What happens if the organization defers the decision another fiscal cycle or two. This is where the status-quo-as-risk framing lands.
Slide 3: The proposed direction. Names the recommended path forward. Cloud-native, multi-tenant financial platform built around a dimensional GL with healthcare-validated reporting (Sage Intacct is the platform that meets these criteria for most mid-market healthcare evaluations), phased implementation, specific timeline. A direction-setting slide, with vendor selection rationale moved to the appendix.
Slide 4: The four pillars. Summarizes the value framework. Margin improvement, risk reduction, IT capacity recapture, audit and compliance efficiency. Each pillar gets a one-line headline value claim.
Slide 5: The five-year financial impact. TCO comparison, summary of margin improvement value, projected payback period. Honest ranges, not single-point estimates.
Slide 6: Risk mitigation. The risks of the modernization itself: implementation risk, change management risk, business continuity during transition. How each risk is being managed.
Slide 7: Implementation approach. Phasing strategy, timeline, major milestones. The board does not need a project plan; they need confidence in the approach.
Slide 8: Internal investment required. What the organization is committing beyond external spend: team time, change management investment, sustained executive sponsorship.
Slide 9: Decision asked of the board. The specific decision being requested. Capital authorization, scope approval, sponsorship endorsement, or whatever the governance structure requires.
Slide 10: Appendix. Vendor evaluation summary, partner selection rationale, detailed TCO, integration scope, risk register. The slides board members will return to between meetings.

The Question Behind the Questions

Boards do not approve implementations because the technology argument is compelling. They approve when the strategic argument is compelling and the implementation argument is credible.

The strategic argument is that the current platform constrains the organization’s ability to operate at the speed and clarity that margin pressure demands. The implementation argument is that the path forward is well-scoped, the partner is qualified, the risks are managed, and the internal team is ready.

A case that wins on both registers tends to be a case where the CFO has done the homework, brought the CIO in as a co-author, and stress-tested the model against the questions the board will actually ask.

What DSD Sees in Cases That Hold Up

Across the modernization conversations DSD has been part of, a few patterns recur in the cases that win board confidence.

Honest. Cases that get ratified name what the platform will not solve. They acknowledge the implementation risk. They present ranges with explicit assumptions. Boards respond to that honesty because they have seen too many cases that promised certainty and failed to deliver.
Joint. CFO and CIO sign together. The audit committee chair has been briefed and is supportive. Operational leaders who will be affected have been consulted. The case does not arrive at the board as a finance project. It arrives as an enterprise initiative.
Paced. They give the board enough information to be confident without overwhelming with detail. The detail lives in the appendix. The presentation lives in the four pillars.

The cases that fail are usually not technically weaker. They are organizationally weaker. They have not built the alignment that should have been built before the slide deck was drafted.

A Final Note for CFOs at This Stage

If you are reading this and your organization is approaching a board decision on ERP modernization, you are already further along than most organizations get. The board has accepted the problem. The CIO is partnered with you. The TCO model is built. The implementation budget is drafted.

The work that remains is the work of presentation, not the work of analysis. Make the case once, well, in a way that respects the board’s time and gives them the information they need to support the decision. The CFOs who do this consistently get the answer they wanted. The pattern is repeatable when the underlying work is honest.

Start the Conversation

DSD Business Systems is a Sage Intacct implementation partner specializing in mid-market healthcare organizations. Our consulting team includes former CFOs, Controllers, and Vice Presidents of Finance from healthcare systems. Several have personally presented modernization cases to boards and audit committees on the client side before joining DSD. We know the questions that get asked and the answers that hold up.

If you are preparing to take an ERP modernization case to your board in the next two quarters, we can review the framework with you, pressure-test the assumptions, and offer a perspective from the partner side. Not a pitch. A working session, peer to peer, on whether the case is ready.

See what a board-ready case looks like from the inside.

Schedule a consultation.

Douglas Luchansky

Director, Client Transformation

Want to learn more about Cloud ERP?

Contact us or check out our resource center!

You’ve Heard a Lot About AI. Here’s What It Can Look Like in Sage 100

DSD Business Systems and Endpoint Automation Solutions Deepen Strategic Partnership to Advance Manufacturing Solutions for the Sage 100 Community

What Healthcare Finance Teams Should Budget for in an ERP Migration

The post Healthcare ERP Modernization: Building the Business Case for Your Board appeared first on DSD Business Systems.

SaaS vs. On-Premise ERP for Mid-Market Hospitals: A Rigorous TCO Comparison

DSD Business Systems — Fri, 05 Jun 2026 17:55:33 +0000

Budget season is when ERP decisions actually happen at mid-market health systems. Strategy decks float ideas all year. Capital committees decide.

When the SaaS-versus-on-premise question lands on the capital agenda, most CFOs encounter the same problem. Vendor materials show SaaS winning by a wide margin on five-year cost. Internal IT shows on-premise winning by a narrow margin on year-one cash. Both can be correct. They are measuring different things. And the version of the comparison that lands in front of the board is usually the one prepared by whichever side wrote it.

The CFO needs a third version. One that includes the costs both sides leave out, draws clear lines around what is genuinely uncertain, and gives the board a defensible number rather than a vendor-friendly one.

This guide walks through the categories that belong in a rigorous TCO model for healthcare ERP, where the typical ranges actually land for a mid-market multi-entity health system, and where each model has a real advantage versus a marketing advantage. For the upstream evaluation framework that informs how to assess each platform against these categories, see our earlier post: Cloud-Native Finance Platforms for Healthcare: What CFOs Need to Evaluate.

The Comparison Most Boards See, and Why It Fails

Most TCO comparisons fail in one of two ways.

The vendor version overstates on-premise costs by including aggressive assumptions about IT labor, infrastructure refresh, and downtime that may or may not apply to your environment. It often understates SaaS implementation costs by quoting reference deals that did not have your entity complexity or integration footprint.

The IT version often undercounts on-premise costs because much of the maintenance burden is buried in existing labor budgets. Database administrators, integration engineers, and infrastructure staff are already on payroll, so their hours feel free. They are not free. They are committed.

The honest TCO model accounts for both. It uses real labor numbers, real infrastructure costs, and realistic implementation estimates for your specific entity count and integration scope. It tells you what each option costs the organization, not what makes either option easier to defend.

The Categories That Belong in the Model

There are nine cost categories that materially affect ERP TCO for mid-market healthcare organizations. Build the model with all nine. Skipping any of them is how comparisons get distorted.

Category 1: Software Licensing

On-premise. Perpetual license fees with annual maintenance (commonly a meaningful percentage of license cost per year). Often front-loaded, with a large year-one outlay that the CFO has to capitalize and depreciate. New modules require additional licensing.

SaaS. Subscription-based, usually billed per user per month or per entity per year. Predictable, treated as operating expense, scales with adoption. The headline number often looks higher than annual on-premise maintenance, but the comparison is misleading until you add infrastructure and IT labor.

Use your vendor’s actual quote and your historical maintenance invoices to fill in the five-year licensing line. This is where vendor decks usually stop. This is also where the comparison is least meaningful.

Category 2: Infrastructure

On-premise. Servers, storage, networking, backup systems, disaster recovery infrastructure. Capital expenditure with depreciation schedules and refresh cycles (commonly every several years). Power, cooling, and data center costs allocated from facilities. A redundant DR site materially increases infrastructure expense if you do not currently have one.

SaaS. Included in the subscription. No capital outlay, no refresh cycle, no DR build. The vendor’s infrastructure is your infrastructure.

Pull your actual infrastructure costs from finance and IT for the on-premise line; the SaaS line is included in subscription pricing.

Category 3: IT Labor

On-premise. Database administration, infrastructure management, version upgrade coordination, integration maintenance, backup and recovery operations, security patching. In a hiring environment where healthcare IT teams are stretched, this labor competes directly with cybersecurity, EHR optimization, and digital initiatives.

SaaS. Reduced significantly. Database administration disappears. Version upgrades become release-note reviews. Integration maintenance shifts from reactive to proactive, but does not vanish.

This is usually the single largest line item in a properly built TCO model. It is also the one most often understated, because the labor sits inside existing payroll and feels free. It is not free. It is committed. The audit in our earlier post for CIOs is the source for the on-premise number; the SaaS number comes from translating that audit to the post-migration state.

Category 4: Implementation

On-premise. Implementation is real, but the organization may have already absorbed it years ago. The relevant comparison is not historical implementation cost. It is the cost of a re-implementation (often required when the platform hits end-of-life or when significant customizations need to be unwound).

SaaS. Fresh implementation. The cost depends materially on entity complexity, integration scope, and the depth of process redesign required. Ask the implementation partner for a quote based on your specific environment, and ask for references at organizations with similar entity counts and EHR platforms.

If the project needs to extend across a longer timeline, the right phasing approach is by module rather than by entity (going live with core modules first and adding nice-to-haves later). Phasing by entity introduces design and training fragmentation that is rarely worth the smoother cash flow.

Category 5: Integration

On-premise. Existing integrations have an ongoing maintenance cost (covered in IT labor above) but no new build cost unless systems are being added or changed. New integrations on legacy platforms are typically built as flat files or batch jobs, which are cheaper to build but expensive to maintain.

SaaS. Re-implementation of integrations to EHR, payroll, AP automation, and other systems. Cost depends on the number of integrations and whether prebuilt connectors are available. API-native integrations are more expensive to build than flat-file approaches and significantly cheaper to maintain over the long term.

Category 6: Customization and Reporting

On-premise. Customizations have accumulated over the life of the platform. Many of them break during version upgrades, which is one reason on-premise upgrades feel so painful. Custom reports require database queries and skilled developers.

SaaS. Healthcare-validated platforms ship with healthcare-specific dimensions, report templates, and dashboards. The custom development burden drops substantially. Reports that took weeks of developer time on the legacy platform often exist out of the box. Sage Intacct is the platform DSD recommends in this space; its HFMA peer-reviewed financial reporting library is one of the reasons mid-market hospital finance teams shorten the report-build timeline meaningfully after migration.

Where on-premise still wins. Extreme customizations that have been built over years and would need to be rebuilt or rationalized during migration. If your organization runs a heavily customized GL structure or has unique workflow requirements that pre-date current best practices, expect implementation effort to skew higher.

Category 7: Training and Change Management

On-premise. Ongoing training costs are typically lower because the platform changes infrequently. Onboarding new finance staff requires training on a system that often has limited documentation and inconsistent UI patterns.

SaaS. Initial training is more substantial because everyone is learning a new platform. Ongoing training is lighter because the platform is documented publicly, UI patterns are consistent, and the vendor maintains training resources. Onboarding new hires gets easier over time.

Treat training and change management as a real line item, not a footnote. Projects that under-invest here usually pay for it in user adoption problems later.

Category 8: Risk and Compliance

On-premise. Audit trail reconstruction, security incident response, business continuity, and compliance documentation are all internal responsibilities. Audit costs are typically higher because supporting documentation lives across multiple systems and workpapers.

SaaS. Audit trails are native to the platform. Compliance certifications (SOC 1, SOC 2, HIPAA-aligned hosting) come with the vendor. Audit costs typically drop after migration, driven primarily by reduced support effort during fieldwork and cleaner trails.

Quantify the risk reduction in dollar terms. A material control weakness or a delayed audit has cost implications well beyond fee savings.

Category 9: Opportunity Cost

The category vendors do not price, because it is hard to. But it is real.

What is your organization not doing because of the current platform? Service-line profitability analysis that would change capital allocation decisions. Continuous close that would shorten the gap between operational reality and financial reporting. AP automation that would unlock early-payment discounts. Real-time consolidation that would let the board see month-end financials before mid-month. Driver-based forecasts that respond to payer-mix shifts the same week the data arrives, because the planning module shares a data model with the GL.

Sage Intacct’s tighter planning-plus-GL integration is one of the reasons it shows up so often in mid-market healthcare evaluations: scenario modeling against live financial data is a daily capability rather than a quarterly project.

Mid-market hospitals on legacy platforms commonly run close cycles materially longer than what cloud-native platforms support. That compression is not just an efficiency gain. It is decision velocity. In a margin environment as compressed as today’s healthcare market, faster decisions are rewarded disproportionately.

Putting It Together: A Five-Year Range

For a typical mid-market multi-entity health system, the directional comparison across three scenarios usually looks like this once all nine categories are accounted for.

Scenario	Five-Year Total Cost (Directional)
On-premise (status quo, no re-implementation)	Higher than vendor decks suggest, once IT labor is fully loaded
On-premise (with end-of-life re-implementation in years 2 to 3)	Highest of the three scenarios
SaaS (full migration with phased implementation)	Lowest, in most mid-market healthcare scenarios

The absolute figures depend heavily on your entity count, integration footprint, and how aggressively you account for IT labor and opportunity cost. Run the model with your numbers. The relative position of the three scenarios is what matters more than the absolute figures, and in most mid-market healthcare environments today the relative position is consistent with the directional pattern above.

Where On-Premise Still Wins

There are real scenarios where on-premise is the better answer for now. Be honest about them in your model.

If your platform is recent, well-supported, and the team is genuinely small and stable, the maintenance burden may not be material. Migration cost will exceed migration value over a three-to-five-year horizon.

If your organization has unique workflow requirements that current SaaS platforms have not yet caught up with, the gap may favor staying put until those gaps close. This is increasingly rare in healthcare finance but still occurs.

If a major M&A event or restructuring is imminent and would disrupt an implementation, sequence matters. Sometimes the right call is “not yet, here is the trigger that would change our answer.”

Where SaaS Wins by a Margin That Should Move the Decision

For the typical mid-market health system in 2026, the case favors SaaS clearly when one or more of the following are true.

The current platform is on or near end-of-life and a re-implementation is on the horizon either way.
IT capacity allocated to ERP maintenance is a meaningful share of the team and the strategic backlog is significant.
The current close runs materially longer than what the executive team needs.
Integration with the EHR is a known operational pain point.
The audit committee has flagged financial reporting timeliness as a concern.
Service-line profitability reporting requires manual rebuilding every cycle.
The organization is in growth mode — adding facilities or service lines currently requires proportional growth in back-office finance and accounting headcount.

When two or more of these are present, the TCO model should show SaaS winning by enough margin that the decision is not close. The growth-mode case in particular is where Sage Intacct’s dimensional architecture earns its differentiation: adding a facility is a configuration task rather than an implementation project, so back-office headcount does not have to scale linearly with the entity count.

Using This Model in the Capital Committee

The board does not need a 200-line spreadsheet. It needs a single page that shows the nine cost categories, the assumptions behind each, and the five-year totals for two or three scenarios. The defensible version is the one where assumptions are explicit and where the categories most often left out (IT labor, opportunity cost, audit cost, integration maintenance) are present.

When the comparison is built honestly, the math usually does its own work. The CFOs who present it well are the ones who did not over-claim. They presented ranges, named uncertainties, and let the board reach the same conclusion from the same data.

Once the TCO model is built, the next step is packaging the case for the board.

Start the Conversation

DSD Business Systems is a Sage Intacct implementation partner specializing in mid-market healthcare organizations. Our consulting team includes former CFOs, Controllers, and Directors of Finance from healthcare systems who have built TCO models on both sides of the migration. We have run the analysis from the inside, in capital committees, with audit committees pushing back.

If you are building a TCO model for your fiscal year planning cycle, we can pressure-test your assumptions against patterns we have seen at similar organizations. We are not going to inflate the SaaS case to win the work. The CFOs we talk to do not respond well to inflated cases, and neither do their boards.

See what your TCO model looks like with the categories most decks leave out.

Schedule a consultation.

Douglas Luchansky

Director, Client Transformation

Want to learn more about Cloud ERP?

Contact us or check out our resource center!

You’ve Heard a Lot About AI. Here’s What It Can Look Like in Sage 100

DSD Business Systems and Endpoint Automation Solutions Deepen Strategic Partnership to Advance Manufacturing Solutions for the Sage 100 Community

What Healthcare Finance Teams Should Budget for in an ERP Migration

The post SaaS vs. On-Premise ERP for Mid-Market Hospitals: A Rigorous TCO Comparison appeared first on DSD Business Systems.

DSD Business Systems and Endpoint Automation Solutions Deepen Strategic Partnership to Advance Manufacturing Solutions for the Sage 100 Community

Tamara Nenninger — Thu, 04 Jun 2026 19:13:53 +0000

SAN DIEGO, CA June 4th 2026 / PRNewswire /
DSD Business Systems, a Diamond Sage Business Partner and Sage Tech Partner, today announced a deepened strategic alliance with Endpoint Automation Solutions (formerly Scanco), a provider of cloud-based operations management software.

The expanded partnership builds on a long-standing relationship between the two organizations, renewed by Endpoint’s recent partner program redesign and refreshed go-to-market strategy. Together, the two companies are entering a new chapter defined by tighter alignment and a shared commitment to delivering value across the Sage ecosystem.

At the heart of the partnership is a meaningful technical collaboration. DSD’s Technology Division is actively engaged at the product level with Endpoint, supporting the continued development of Operations Management for Sage 100 alongside its own catalog of more than 500 proprietary Sage 100 enhancements. This partnership ensures that Sage 100 clients continue to have access to robust, forward-looking manufacturing automation solutions — and that the tools they already rely on remain compatible as their operations capabilities grow.

“This partnership goes deeper than most,” said Brett Rozell, Executive Vice President of Sales, DSD Business Systems. “We’re contributing at the product level and expanding what we can offer our clients. That’s a reflection of the technical depth our team brings and the long-term commitment we have to the Sage 100 community — and to making sure our clients always have a path forward that makes sense for their business.“

“Having a partner like DSD engaged at the product level — not just the sales level — is exactly the kind of relationship we’ve built our new partner program to support,” said Kurt Heusner, Chief Executive Officer, Endpoint Automation Solutions. “Their technical depth and commitment to the Sage 100 community makes them an ideal partner as we continue to grow.“

About DSD Business Systems

Since 1984, DSD Business Systems has been a trusted Sage partner — committed to innovation and the cutting-edge solutions that help businesses thrive. A Diamond-level Sage partner, one of the top three largest Sage VARs in the United States, and a perennial member of Sage’s President’s Circle, DSD’s Technology Division has led Sage software development for over 35 years, producing more than 500 proprietary Sage 100 enhancements for thousands of clients across North America. Learn more at www.dsdinc.com.

About Endpoint Automation Solutions

Endpoint Automation Solutions (formerly Scanco) has been delivering warehouse, manufacturing, and operations automation software since 1989. Serving thousands of satisfied end users across numerous ERP platforms, Endpoint provides mobile warehouse management, manufacturing operations, procurement, mobile sales, and payments solutions that help businesses streamline operations and focus on growth. With a 90%+ customer retention rate and over 36 years of industry experience, Endpoint is a trusted partner for mid-market organizations navigating digital transformation. Learn more at https://endpointas.com/.

For inquiries, contact:
Kimberly Tucker
DSD Business Systems
Email: marketing@dsdinc.com
Phone: 800-627-3092

The post DSD Business Systems and Endpoint Automation Solutions Deepen Strategic Partnership to Advance Manufacturing Solutions for the Sage 100 Community appeared first on DSD Business Systems.

11 Signs Manufacturers Need an Integrated Cloud ERP in 2026

Megan Pawlowski — Wed, 03 Jun 2026 18:18:50 +0000

Growing a manufacturing business is exciting, until your software starts holding you back. If you’re running production on basic accounting and inventory tools, you may be hitting walls you didn’t see coming. DSD Business Systems helps manufacturers identify when it’s time to move beyond entry-level software and adopt an integrated cloud ERP built for production.

This guide walks through 11 warning signs that signal your current tools can no longer keep pace. From inventory inaccuracies to multi-entity complexity.

The 11 warning signs for manufacturing ERP evaluation

What are the operational warning signs that signal you’ve outgrown basic software?

Manufacturers typically recognize they’ve outgrown basic accounting and inventory software when daily operations require workarounds that consume more time than the actual work. According to industry research, inventory accuracy improves by 25% after ERP implementation, highlighting how much visibility basic tools leave on the table.

Here are the specific warning signs to watch for:

1) Spreadsheet dependency: You’re maintaining inventory counts, production schedules, or job costs in spreadsheets because your software can’t handle the complexity needed

2) Inventory discrepancies: Physical counts regularly differ from system records, leading to stockouts or excess inventory

3) Manual data entry: Your team re-enters the same information across multiple systems, sales orders, production, shipping, accounting

4) Delayed financial close: Month-end takes weeks because you’re reconciling data from disconnected sources

5) No real-time visibility: Answering “what’s our inventory status?” requires pulling reports, checking spreadsheets, and calling the warehouse

6) Job costing gaps: You can’t accurately determine profitability by job, product, or customer without extensive manual analysis

7) Multi-location complexity: Managing inventory and transactions across facilities requires duplicate data entry or error-prone transfers

8) Production planning by memory: Scheduling relies on tribal knowledge rather than system-driven capacity planning

9) Compliance concerns: Lot tracking, traceability, and audit trails require manual documentation outside your core system

10) Growth constraints: Adding products, customers, or facilities means exponentially more manual work

11) System performance issues: Your software slows down as transaction volumes increase

When should manufacturers start evaluating additional ERP options?

The right time to evaluate a new ERP is before your current tools create a crisis. Waiting until spreadsheets collapse or inventory errors cost you a major customer puts you in reactive mode. According to industry data, manufacturing accounts for 32% of total ERP spending, the largest vertical because production environments demand integrated systems.

Start your evaluation when you notice any of these patterns:

Your finance team spends more time gathering data than analyzing it

Operations staff have created personal systems (spreadsheets, notebooks, whiteboards) to track what the software misses

You’ve delayed adding products or locations because your systems can’t handle the complexity

Why Acumatica is The Solution for Manufacturers

Finding the right ERP means looking beyond basic accounting features. You need software that understands production workflows, tracks costs at the job level, and gives you real-time visibility into shop floor operations.

Here’s what we evaluated:

Production planning capabilities: Can you schedule production orders, manage work-in-progress, and track labor costs without building spreadsheet workarounds?
Inventory accuracy: Does the system support lot tracking, multiple locations, and real-time stock visibility across your entire operation?
Financial integration: Can you see job costs, margins, and variance reports without exporting data to external tools?
Multi-entity support: If you run multiple locations or companies, can transactions flow automatically without manual reconciliation?
Shop floor connectivity: Does the system connect to your production environment for backflushing, labor tracking, and material consumption?
Scalability: Will this system handle increased transaction volumes, new product lines, and additional facilities as you grow?

Why DSD is a standout Gold Certified Acumatica Cloud partner for manufacturers

DSD stands out because they combine software expertise with manufacturing industry knowledge. As a 2025 and 2026 Acumatica President’s Club winner with over 40 years in the software business, DSD brings credibility that generic software partners can’t match. Our team evaluates your production workflows, identifies system requirements, and recommends solutions that address your actual challenges, not generic feature lists.

This people-first approach means you work with consultants who understand manufacturing operations, not just software configuration.
For manufacturers ready to move beyond basic accounting and inventory software, DSD delivers the expertise and solutions to support your growth. Request a demo to see how Acumatica Manufacturing can address the warning signs holding your operation back.

FAQs about manufacturing ERP for growing businesses

What’s the difference between accounting software and manufacturing ERP?

Basic accounting software tracks financial transactions, invoices, payments, and general ledger entries. Manufacturing ERP connects those financials to production operations, including bills of materials, work orders, shop floor tracking, and job costing.

We help you understand which capabilities your operation actually needs, so you’re not paying for features you won’t use.

Can I keep using QuickBooks alongside manufacturing ERP?

Some manufacturers phase their transition, running basic accounting in QuickBooks while adopting production-specific modules. However, this approach creates integration challenges and data silos that often negate the benefits of ERP.

We recommend evaluating whether a full transition to integrated ERP delivers better long-term value than maintaining multiple systems.

What training do my employees need for manufacturing ERP?

Training requirements depend on each role’s interaction with the system. Shop floor staff may need a few hours on production reporting, while finance teams require deeper training on costing and reporting modules.

We include role-based training in their implementation methodology, ensuring each team member learns the specific functions they’ll use daily.

How does DSD Business Systems support manufacturers after go-live?

We offer ongoing support services for all their software solutions. Their support team handles technical issues, while consultants remain available for process optimization and additional training as your team’s needs evolve.

Final Thoughts: How does DSD Business Systems support manufacturers after go-live?

DSD offers ongoing support services for all their software solutions. Our support team handles technical issues, while consultants remain available for process optimization and additional training as your team’s needs evolve over time.

This national presence and people-first approach means you have access to expertise whenever questions arise, not just during implementation.

Want to learn more about Acumatica?

Contact us today!

Acumatica 2026 R1: Powerful AI-Enabled Innovation to Scale Faster

Acumatica Cloud ERP Empowers Electrical Contractors

Maximize Process Manufacturing Efficiency with Acumatica

The post 11 Signs Manufacturers Need an Integrated Cloud ERP in 2026 appeared first on DSD Business Systems.

What Healthcare Finance Teams Should Budget for in an ERP Migration

DSD Business Systems — Tue, 02 Jun 2026 22:13:03 +0000

The decision to modernize the financial platform is usually made at the strategic level. The decision to fund it is made in much more practical terms. Once a CFO says “we are seriously considering this for next year,” the next question is always the same.

What is this actually going to cost us?

Vendor decks answer that question optimistically. Implementation partner proposals answer it precisely for their scope of work, which does not include everything you will spend. The honest answer requires accounting for all the line items, including the ones that do not show up on either party’s invoice.

This is a budgeting guide for healthcare finance teams preparing to move from a legacy on-premise ERP to a cloud-native platform like Sage Intacct. Numbers will vary with your specific environment, entity structure, and integration scope. The categories and the relative weight of each one tend to hold across mid-market healthcare.

How much should we budget total for an ERP migration?

The honest answer is that year-one all-in cost varies significantly depending on entity complexity and integration scope. Plan for a meaningful capital request that includes platform subscription, implementation services, integration work, internal labor opportunity cost, training, and contingency. Build the budget from your specific environment rather than benchmarks; pattern numbers are not a substitute for a quote against your actual scope.

Year two drops materially once implementation services drop off. Subscription and ongoing optimization become the bulk of the run cost. By year three, total annual run cost is typically lower than the comparable on-premise total cost.

The number that matters more than the headline is the year-by-year cash flow profile. CFOs presenting to capital committees should expect a question about year-one peak spending. Have an answer that includes phasing options.

What is the typical split between platform cost and implementation cost?

In year one, expect platform subscription and implementation services to each represent a substantial portion of the total, with the balance going to integration build, training, internal labor coverage, and contingency.

That “everything else” bucket is where projects most often go over budget. Implementation partners price their scope cleanly. Subscription costs are fixed. The variance lives in the work that sits between the two: integrations, change management, and the operational prioritization required when the team takes on the implementation alongside their existing close responsibilities.

How long does a typical implementation take?

Implementation length varies materially with entity count, integration footprint, and historical customization. A focused, well-scoped Sage Intacct implementation can move quickly; complex multi-entity organizations with extensive EHR integration and significant historical customization take longer. Your implementation partner should be able to give you a firm timeline once they understand your specific environment. Intacct’s multi-tenant architecture means the platform itself does not require a custom build; the implementation effort is concentrated in configuration, integration, and process design.

If the project needs to span a longer timeline, the right approach is to phase by module (going live with core modules first, then adding nice-to-haves), not by entity. Module phasing keeps the full user community engaged in the design phase and avoids the rework that entity-by-entity rollouts typically generate.

The timeline includes structured user acceptance testing in a dedicated test environment, not a parallel run. DSD does not recommend running the legacy system and the new platform side by side; that approach doubles the workload and rarely catches issues that proper test-environment testing would not. The implementation instead includes thorough UAT scenarios for the meaningful transactions: anything complex, anything that occurs on a regular cadence, anything that touches multiple modules. When those scenarios pass cleanly in the test environment, the team is ready to cut over.

Who needs to be on our internal team, and how much of their time?

The implementation partner does the configuration work. Your team owns process design, data validation, user acceptance testing, and change management.

Plan for these internal roles during the implementation window:

Role	Typical Owner	Time Commitment	Focus
Project sponsor	CFO	Light	Steering committee, escalations, major decisions
Project lead	Controller or VP of Accounting	Substantial; effectively a primary role	End-to-end execution during active implementation
Functional leads	AP, AR, GL, payroll allocation, consolidation owners	Material per lead	Process design, configuration sign-off, testing
IT lead	Director of IT or VP of Applications	Material	Integration design, security, identity management
Power users / change champions	One per business unit	Modest, sustained	Testing, training delivery, adoption

The project lead commitment is the one organizations consistently underestimate. Trying to add a part-time-but-substantial workload on top of an existing full role is the most common reason implementations slip. Plan for explicit workload reallocation, extended deadlines on competing work, or leadership commitment to deprioritize other initiatives during the implementation window.

Beyond the project lead specifically, plan for the broader team to take on additional time and project commitments during the implementation window. The work does not get done unless leadership explicitly prioritizes it, and that prioritization needs to come with a real plan: extended deadlines on lower-priority work, deliberate reallocation of workload across the team, or operational priority shifts. Competing priorities are the most common reason implementations slip or get back-burnered. Recognize that risk upfront and budget for it in both time and cost.

What does year two look like?

Year two budget should reflect three things.

Steady-state subscription costs. The headline platform cost continues at the negotiated rate. Modules added during implementation are now baseline. Module additions in year two are predictable.

Ongoing platform support and optimization. Year two is when most clients move from active implementation services to a steady-state support model. With DSD, that means a service-level agreement: a fixed annual cost that covers platform support, optimization, and release adoption guidance. The SLA replaces what would otherwise be unpredictable hourly consulting invoices, and it keeps the platform improving without forcing the finance team to forecast support spend quarter by quarter.

Training for new hires and refresh training for existing users. The platform is easier to onboard people to than the legacy system, but it is not zero-effort. Plan for an annual training line.

Year two is also when the IT labor recovery starts showing up in real terms. Capacity that was committed to ERP maintenance becomes available for the strategic backlog. Most CIOs do not reduce headcount; they redirect it. That redirection is the largest source of TCO improvement in the model.

What gets cut from the implementation budget that should not?

Three things, consistently.

Data cleanup. The temptation is to start implementation with the data you have and clean it up later. Do not. Open intercompany items, unreconciled accounts, abandoned customizations, and orphaned dimensions are easier to address before migration than after. Build a meaningful pre-implementation window into your timeline for this, and budget for external support if the current GL is in rough shape.

User acceptance testing time. UAT is the workstream most often compressed when timelines slip. Compressed UAT means defects surface in the first live close instead of in the test environment, which is a much more expensive place to find them. Hold the line on UAT duration and the number of test scenarios.

Test data preparation. UAT only works if the test data reflects production realities. Organizations sometimes cut this step, then discover during go-live that scenarios they should have tested never appeared in the test environment. Budget the time to build representative test data, including the edge cases that historically caused problems on the legacy platform.

What are the hidden costs we should account for?

Three categories typically surprise CFOs.

Custom report rebuild. The reports your finance team built over years on the legacy platform need to be evaluated, prioritized, and rebuilt on the new platform. Most will be replaced by out-of-the-box reports. A subset will require custom development. Build a dedicated line item for report migration work.

Add-on and third-party software licensing. Most modern healthcare ERP implementations bring in a few specialized add-ons (AP automation, expense management, advanced budgeting, industry-specific integrations) that carry their own licensing. These costs are not part of the core platform subscription and typically sit outside the implementation partner’s fixed fee. Confirm which add-ons are recommended for your environment, what they cost annually, and which ones are billed by the platform vendor versus the third-party provider.

Audit support during transition. Your external auditors will have additional procedures the first year on the new platform. Plan for higher audit fees in year one. This normalizes by year two, and audit fees typically come in lower than the legacy baseline thereafter.

Should we phase the rollout across entities?

DSD does not recommend phasing the rollout across entities unless the organization absolutely needs to. The cost premium is real and the benefits typically do not materialize.

The bigger issue is design quality. When some user groups are not involved until late in the project, they may surface requirements or workflow concerns that would have shaped the original system design. By the time those concerns surface, the teams already live on the system have to revisit configurations and processes that were assumed to be settled. Training and testing get fragmented across waves, and the user community ends up contributing unevenly to how the platform is built out.

If you need to spread the project out across a longer timeline, phase by module rather than by entity. Go live with the must-haves first (core GL, AP, AR, consolidations, reporting), then layer on the nice-to-haves later (fixed assets, advanced budgeting, additional integrations). Everyone is in the system from go-live, but the platform’s functional footprint expands over time. The cost stays controlled, the full user community contributes throughout the design phase, and the timeline can extend without the design fragmentation that comes with entity-by-entity phasing.

What about change management as a budget line?

Treat change management as a meaningful percentage of total implementation cost. The exact share varies, but underfunding this category is one of the most consistent ways to inherit problems after go-live. The work includes stakeholder communications, training development, user adoption tracking, and resistance management.

Organizations that under-fund this category usually end up paying for it later in three forms: lower user adoption, additional training cost in years two and three, and persistent reliance on workarounds the platform was supposed to eliminate.

When do we budget for additional consulting after go-live?

For DSD customers, the first year of go-live support is included in the statement of work. That covers stabilization in the early weeks, training reinforcement as the team settles into the platform, and optimization work that emerges from the first few close cycles. Most of what other partners price as separate post-go-live consulting hours is already in scope.

Starting in year two, we recommend clients move to a DSD service-level agreement. The SLA is a fixed annual cost that covers ongoing platform support, release adoption guidance as Sage Intacct ships new functionality, and incremental optimization. Fixed cost means predictable budgeting; clients know what their year-two-and-beyond support line looks like without surprise consulting invoices.

What is not in the SLA: net-new projects. If you decide to add a module, integrate a new system, or take on a process redesign that goes beyond optimization, that becomes its own scope and its own budget line. Plan for that work explicitly as it comes up, rather than pre-budgeting for it speculatively.

What is the single most important budget conversation to have early?

The conversation with the CIO about IT labor redirection.

ERP modernization is a finance-led initiative most often, but the largest source of value (and the largest risk if mishandled) is the redirection of IT capacity. If the CIO is not part of the budget conversation, the implementation may succeed technically while failing to deliver the strategic value the model was built on. Plan that conversation early, document the alignment, and revisit it after go-live.

Final Thought

Budgets that work share two characteristics. They are honest about the full cost. And they are explicit about what the organization is buying.

You are not buying a platform. You are buying capacity, speed, and decision velocity. The platform is the vehicle. Treat the budget that way and the conversation with the capital committee gets easier, because you are not justifying software costs. You are justifying organizational capability.

Start the Conversation

DSD Business Systems is a Sage Intacct implementation partner specializing in mid-market healthcare organizations. Our consulting team includes former CFOs, Controllers, and Directors of Finance who built implementation budgets on the client side before they ever built one on the partner side. We know the questions capital committees and audit committees ask, and we know which answers hold up under scrutiny.

If you are heading into fiscal-year planning with ERP modernization on the table, we can walk through a budget framework calibrated to your specific entity count, integration scope, and team capacity. Not a quote. A framework you can defend.

Build a budget your capital committee will believe.

Schedule a consultation.

Douglas Luchansky

Director, Client Transformation

Want to learn more about Cloud ERP?

Contact us or check out our resource center!

You’ve Heard a Lot About AI. Here’s What It Can Look Like in Sage 100

DSD Business Systems and Endpoint Automation Solutions Deepen Strategic Partnership to Advance Manufacturing Solutions for the Sage 100 Community

What Healthcare Finance Teams Should Budget for in an ERP Migration

The post What Healthcare Finance Teams Should Budget for in an ERP Migration appeared first on DSD Business Systems.

Free Your IT Team from Legacy ERP Maintenance: A Practical Playbook for Hospital CIOs

DSD Business Systems — Tue, 02 Jun 2026 19:14:35 +0000

If you are running applications at a mid-market hospital, you already know where your team’s hours actually go. Not to the digital front door. Not to the EHR optimization roadmap. Not to the cybersecurity work the board keeps asking about. The hours go to keeping the financial platform standing.

Patches. Batch job failures. Middleware updates. EHR-to-GL integration scripts that break every time the source system ships a release. A monthly close that depends on three people on your team being available to troubleshoot when the data does not land where it should.

This is the legacy ERP maintenance burden. It is invisible in the project portfolio because nothing about it looks like a project. It is just the cost of running. And until you quantify it, the modernization conversation never moves forward, because nobody can see what you are actually paying.

This playbook is for CIOs and VPs of Applications who suspect their team is over-allocated to ERP maintenance but have not yet built the case internally. The goal is not to sell you on a platform. The goal is to give you a structured path from problem recognition to modernization readiness, so that when the finance team brings up cloud ERP again, you are the one with the data.

Here are the six steps.

Step 1: Quantify the Maintenance Burden in FTE Terms

You cannot make the case for change with a feeling. You need the number.

Pull your team’s time data for the last 90 days and tag every ticket, incident, and project-coded hour that touched the ERP, its integrations, or its supporting infrastructure. Include the obvious work (database administration, backup management, version patching) and the less-obvious work (helping finance staff troubleshoot exports, rebuilding broken file transfers, answering “did the batch run last night?” questions on Monday mornings).

If you do not have ticket-level tagging, run a structured interview with each member of your applications and infrastructure teams. Ask three questions:

What ERP-related work did you do this week?
How many hours did it take?
How much of it was reactive (something broke) versus proactive (planned maintenance or improvement)?

Aggregate the answers. Convert hours to FTE equivalents. The number is almost always higher than IT leaders expect when they first put it in writing. That is a budget line item your team is paying without ever seeing it priced.

Document the split between reactive and proactive work. The reactive percentage is the more important number. When the majority of ERP-related hours are reactive, your team is not maintaining a platform. They are stabilizing it.

Step 2: Map the Integration Architecture

Most legacy ERP maintenance does not happen inside the ERP. It happens at the seams between systems.

Draw the integration architecture between your financial platform and every system it touches: the EHR, payroll, AP automation, supply chain, revenue cycle, donor management for the foundation, the bed management system, anything that exchanges data with the GL. For each connection, document four things:

Method:

Flat file transfer, scheduled batch job, custom middleware, point-to-point connector, or API.

Direction:

One-way or bidirectional.

Frequency:

Real-time, hourly, nightly, weekly, ad hoc.

Owner:

Which team or person on your staff is on the hook when it breaks.

This map almost always surprises the CIO. The number of unique integration patterns is higher than expected. The dependence on specific staff members for specific connections is higher than expected. And the percentage of connections built on fragile methods (flat files, batch jobs, undocumented middleware) is usually well over half.

For a deeper look at why those fragile methods accumulate and how API-native architecture changes the model, see our earlier post: Open APIs for EHR Integration: How Cloud ERP Eliminates Integration Spaghetti.

The map is the artifact you use later when finance asks “what would it take to move?” You already know. The map tells you.

Step 3: Identify the Capacity Your Team Is Not Spending Elsewhere

Maintenance hours are not just hours. They are hours not spent on the work your CIO peers are doing at organizations that already modernized.
List the strategic initiatives your team should be advancing but has deferred or under-resourced because of ERP maintenance load. Common examples:

Clinical systems optimization:

Epic upgrades, Cerner consolidation, EHR workflow improvements.

Cybersecurity hardening:

Zero-trust architecture, identity management, ransomware preparedness.

Patient-facing digital initiatives:

Patient portals, telehealth, scheduling automation.

Data and analytics maturity:

Clinical data warehouse, population health analytics, dashboarding.

AI and automation pilots:

Clinical documentation, revenue cycle automation, operational forecasting.

For each, estimate the team capacity that would be required to move it forward and compare it to what you have available after maintenance is accounted for. The gap is your opportunity cost. It is the work that is not getting done because the ERP keeps demanding hours.

For a concrete example of the kind of capacity that gets unlocked on the finance side when these patterns change, see our earlier post: 20+ Hours of Manual Imports, Gone: What the EHR-to-GL Workflow Looks Like After Cloud Migration. The IT-side version of that same story is the redirection this step is asking you to quantify.

This list does two things. It changes the modernization conversation from defensive (we need to fix what is broken) to offensive (we need to redirect capacity to what we cannot currently do). And it gives your CFO and CEO peers a concrete picture of what your team could deliver if the maintenance burden lifted.

Step 4: Define What "Liberation" Actually Looks Like

Vague target states do not build business cases. Specific ones do.

For each of the maintenance categories you documented in Step 1, define what success looks like on a modern platform. Be precise. Use your own numbers from Step 1 in the table; the directional pattern looks like this.

Maintenance Category	Legacy ERP (Current)	Multi-tenant SaaS like Sage Intacct (Target)
Database administration	Active capacity on patching, backups, performance tuning	Near zero; vendor manages infrastructure
Integration maintenance	Heavy capacity on file transfers, batch monitoring, middleware patching	Reduced to configuration and exception monitoring on an API-native platform
Version upgrade coordination	Annualized capacity on planning, regression testing, deployment	Minimal; continuous updates on the vendor’s schedule, not yours
Custom report development	Ad hoc finance requests requiring database queries	Reduced as finance self-serves from healthcare-validated reports

A note on the integration line: APIs do not eliminate integration work, but they change the nature of it from reactive maintenance to proactive configuration.

The total reclaimable capacity from this exercise is the centerpiece of your business case. Whatever your specific numbers turn out to be, the value is in expressing the maintenance burden in the only language your CFO needs: people, hours, and what they could do instead.

Step 5: Build the Cross-Functional Case Before You Need It

CIOs who go to the board alone with an IT modernization argument tend to lose. CIOs who arrive with the CFO and the CEO already aligned tend to win.

Start the alignment work early. Bring your numbers from Steps 1 through 4 to the CFO. Frame the conversation around shared outcomes, not technical preferences.

Lead with capacity

Show what your team is spending on maintenance today and what could be redirected. In a hiring environment where administrative vacancies remain elevated across healthcare, the idea that you can recover meaningful IT capacity without adding headcount is consistently interesting to a CFO.

Connect to the finance team's pain

Your team’s maintenance hours map directly to delays, errors, and rework on the finance side. The integration that breaks at 2am is the same integration that causes finance to miss its close target. The CFO already knows this from their angle. You are confirming it from yours.

Establish shared ownership of the case

The strongest modernization arguments are joint. CFO owns the financial value (close time, margin visibility, board reporting). CIO owns the operational value (capacity, risk, integration architecture). When the case goes to the board with both signatures, it does not look like an IT pet project. It looks like enterprise transformation.

Be honest about what modernization will require from finance

Implementation is not something you outsource entirely to a partner. The finance team will need to invest meaningful capacity during the implementation window, often the equivalent of a part-time-but-substantial dedicated role. The CFO needs to plan for that. Surprises on this point derail more projects than budget overruns.

Document the alignment in writing

A one-page joint memo from CFO and CIO, signed by both, is worth more than three deck reviews. It locks in the framing before competing priorities have a chance to fragment it. It also gives the CEO and the audit committee something concrete to react to when the case gets escalated.

Step 6: Establish Modernization Readiness

Before you commit to an evaluation, audit your organization’s readiness across four dimensions.

Sponsorship readiness

Is there an executive sponsor (typically the CFO) who will own the project at the steering committee level? Will the CEO endorse the initiative publicly to the board? Without active executive sponsorship, modernization projects stall the first time scope creep meets resistance.

Data readiness

How clean is your current GL? How many open intercompany items, unreconciled accounts, and legacy customizations need to be addressed before migration? Most healthcare organizations need a dedicated cleanup window before implementation kickoff. Scope it explicitly and build it into your timeline.

Process readiness

Are your close, reconciliation, and consolidation processes documented? If the institutional knowledge lives in three people’s heads, the implementation will be harder than necessary. Documenting current-state processes is a useful pre-implementation exercise regardless of timing.

Change management readiness

How many of your finance, IT, and operational staff have lived through a major system implementation? If the answer is “very few,” budget more heavily for training, communications, and stakeholder management. Cultural readiness is the variable that most often separates implementations that hit their targets from those that drift.

The output of Step 6 is a readiness scorecard. Anything scoring below 3 on a 5-point scale is a workstream you need to address before kickoff, not during it.

Putting the Playbook Together

You now have six artifacts:

A quantified maintenance burden expressed in FTEs.
An integration architecture map.
An opportunity-cost list of strategic initiatives that maintenance is crowding out.
A target-state definition with reclaimable capacity by category.
A cross-functional alignment plan with finance and executive sponsorship.
A readiness scorecard.

Together, these are the structured path from problem recognition to modernization readiness. They are also the briefing document for any modernization conversation, whether it is internal (board, CFO, CEO) or external (an implementation partner, a software vendor, a peer CIO who is further along the path).

The CIOs who run this exercise end up in a different position than the ones who do not. They have data instead of opinions. They have a partnership with finance instead of a turf conflict. And they have a clear-eyed view of what modernization will and will not solve, which is the only foundation that makes the eventual decision durable.

Where DSD Comes In

DSD Business Systems is a Sage Intacct implementation partner specializing in mid-market healthcare organizations. Our consulting team includes former healthcare finance leaders, paired with implementation engineers who have spent years inside hospital IT environments. That combination means we understand both sides of the maintenance burden you are trying to quantify: the IT hours it consumes and the finance-side consequences when those hours run short.

When CIOs work with us, the early conversations look more like peer benchmarking than vendor pitching. We share what other mid-market hospitals saw when they ran a similar playbook. We pressure-test your integration map against patterns we have seen across implementations. We help you build the cross-functional case with finance, because we have built that bridge on dozens of engagements. When the case is ready and the architecture criteria are clear, Sage Intacct is consistently the platform that meets them for mid-market healthcare: multi-tenant, API-native, and built around a dimensional GL.

If you are at the point where you suspect ERP maintenance is consuming more of your team than it should, the next step is the audit in Step 1. Run it. Bring us the numbers. We will tell you what we see, including the parts where the answer is “you are not ready yet, here is what to address first.”

Talk to a partner who knows what this audit looks like from both sides.

Schedule a consultation.

Douglas Luchansky

Director, Client Transformation

Want to learn more about Cloud ERP?

Contact us or check out our resource center!

You’ve Heard a Lot About AI. Here’s What It Can Look Like in Sage 100

DSD Business Systems and Endpoint Automation Solutions Deepen Strategic Partnership to Advance Manufacturing Solutions for the Sage 100 Community

What Healthcare Finance Teams Should Budget for in an ERP Migration

The post Free Your IT Team from Legacy ERP Maintenance: A Practical Playbook for Hospital CIOs appeared first on DSD Business Systems.

20+ Hours of Manual Imports, Gone: What the EHR-to-GL Workflow Looks Like After Cloud Migration

DSD Business Systems — Wed, 27 May 2026 19:56:04 +0000

Every month, finance teams of hospitals and clinics across the country run the same routine. Data gets pulled out of the EHR. It gets reformatted in Excel. It gets manually loaded into the financial system. Then someone checks it, because the last time nobody checked it, the numbers were wrong for two weeks before anyone noticed.

Add payroll allocations, AP invoice data, and operational statistics to that cycle, and you are looking at 20 or more hours of staff time per month dedicated to moving data between systems that should be talking to each other.

This is not a technology problem in the traditional sense. The systems work. The data exists. The issue is that the connection between them was built with flat files, batch jobs, and manual workarounds instead of a modern integration architecture. And every month, your team pays for that gap in hours.

Here is what those 20+ hours actually consist of, where the time goes, and what each workflow looks like when the manual layer is replaced with automated, API-driven data flows on a cloud financial platform like Sage Intacct.

Workflow 1: EHR Charge and Payment Data

This is typically the largest single source of manual import time.

The manual process. The EHR (Epic, Cerner, athenahealth, eClinicalWorks, or similar) generates a nightly or weekly export of charges, payments, and adjustments. The file lands on an SFTP server or shared directory. Someone on the finance team picks it up, opens it, and reformats it to match the GL account structure. Charge codes get mapped to revenue accounts. Payer categories get assigned. Adjustments get classified. The reformatted data gets imported into the financial system, usually through a CSV upload or a custom import utility.

When the file format changes (and it does, often after EHR updates), the import breaks. The team discovers the break the next morning when numbers do not tie. Someone troubleshoots, rebuilds the mapping, and re-imports. That cycle can consume half a day or more, and it happens several times a year.

What this looks like after migration. On Sage Intacct, EHR data flows through an API-based connector. Charges, payments, and adjustments post to the dimensional GL as they occur, mapped to the correct revenue accounts, payer dimensions, and service-line tags through a configuration layer that does not depend on static file formats. When the EHR releases an update, the API connection handles the change through versioning. No broken files. No manual remapping.

According to KLAS (2023), API-level EHR integration with a cloud financial platform shrinks close time by approximately 40%. That is not a theoretical number. It reflects the elimination of the manual extraction, reformatting, and verification steps that consume real hours every cycle.

Time Recovered:

6 to 10 hours per month at a mid-market healthcare organization running 5 or more entities.

Workflow 2: Payroll Allocations and Labor Cost Distribution

Healthcare labor costs typically represent 50% to 60% of total expenses. Getting payroll data into the financial system accurately and on time is not optional. But at most organizations, the process is anything but automatic.

The manual process. Payroll runs on its own platform (ADP, Criterion, WFG, or similar). After each pay period, someone exports the payroll journal. That journal needs to be allocated across entities, departments, and cost centers based on where employees worked, not just where they are administratively assigned. For organizations with per-provider labor costing, the allocation is even more granular: by physician, by clinic, by service line.

This allocation is almost always done in Excel. Someone builds a workbook that takes the raw payroll data, applies allocation percentages, and produces journal entries for each entity. The journal entries get manually keyed or uploaded into the financial system. If the allocation percentages change (new hire, departmental reorganization, clinic closure), the workbook needs to be updated before the next cycle.

What this looks like after migration. Sage Intacct integrates with major payroll platforms through connectors that pull payroll data directly into the GL with dimensional tagging. The allocation logic lives in the system, not in a spreadsheet. When an employee’s cost center changes, the allocation updates in the configuration layer. Journal entries are generated automatically. The finance team reviews and approves instead of building from scratch.

The MGMA 2024 data on administrative vacancy rates (exceeding 20% in many healthcare organizations) makes this particularly relevant. When your team is already short-staffed, spending hours on manual payroll allocation is capacity you cannot afford to lose.

Time Recovered:

4 to 6 hours per month, more at organizations with complex per-provider or multi-entity allocation models.

Workflow 3: Accounts Payable and Invoice Processing

AP is a volume game. Mid-market healthcare organizations process hundreds or thousands of invoices per month across supplies, pharmaceuticals, contracted services, and capital items. The manual import burden is proportional to that volume.

The manual process. Invoices arrive by mail, email, and vendor portal. Someone opens each one, keys the data into the financial system (vendor, amount, GL coding, entity, approval routing), and routes it for approval. Paper invoices get scanned and filed. Duplicates get caught (sometimes) through manual checking. Coding errors get discovered during close reconciliation, not at the point of entry.

At many organizations, the AP team maintains a separate tracking spreadsheet alongside the financial system because the system’s native workflow tools are insufficient or too cumbersome to configure. That spreadsheet becomes the real system of record, which creates its own reconciliation burden.

What this looks like after migration: Sage Intacct’s AP automation (and integrated third-party tools) uses OCR capture to extract invoice data, applies coding rules based on vendor and GL history, routes for approval through system-native workflows, and posts the entry automatically upon approval. Duplicate detection is automatic. Coding suggestions are based on historical patterns.

Intacct Cloud data (2024) shows that AP automation reduces the AP cycle from an average of 14 days to under 3, while unlocking early-payment discounts that flow directly to the bottom line. For a healthcare organization operating on 1% margins, those discounts are meaningful.

Time Recovered:

4 to 6 hours per month in direct import and coding time, with additional time savings from reduced reconciliation effort during close.

Workflow 4: Operational Statistics and Non-Financial Data

This is the workflow most organizations forget to count when they estimate their manual import burden. But it adds up.

The manual process. Finance teams need non-financial data to produce meaningful reports: patient volumes, bed occupancy, procedure counts, referral patterns, payer mix by service line. This data lives in the EHR, in scheduling systems, in departmental databases. Getting it into the financial reporting environment requires manual extraction, reformatting, and loading. At some organizations, this is a monthly ritual. At others, it happens ad hoc whenever leadership asks a question that requires operational context alongside financial data.

The problem is not just the time. It is the lag. By the time operational statistics are manually compiled and matched to financial results, the data is weeks old. Service-line profitability reports that combine financial and operational data become stale before they reach the people who need them.

What this looks like after migration. A cloud-native financial platform with an open API layer can ingest non-financial data as dimensions or statistical accounts. Patient volume data, bed occupancy rates, and procedure counts can feed directly into the GL reporting engine alongside financial transactions. Service-line profitability reports that combine revenue, cost, and volume data are produced from a single system instead of assembled from three.

Time Recovered:

2 to 4 hours per month, with the larger impact being report timeliness and relevance.

The Compound Effect: Where 20+ Hours Becomes Something Bigger

Add those workflows together:

Workflow	Monthly Hours (Manual)	Monthly Hours (Automated)
EHR charge and payment imports	6 to 10	< 1
Payroll allocations	4 to 6	< 1
AP invoice processing	4 to 6	< 1
Operational statistics	2 to 4	< 1
Total	16 to 26	< 4

The 20+ hour figure is conservative for a multi-entity healthcare organization. Some organizations we work with were spending closer to 30 before migration, depending on entity count and integration complexity.

But the hours are only part of the story. Each manual import introduces error risk. Each error requires investigation and correction during close. Each correction delays the close timeline. Each delayed close means leadership is making decisions on older data. At 1% margins, the cost of those delayed decisions is harder to quantify but no less real.

The IT side compounds similarly. Every flat file integration, every batch job, every custom import utility requires ongoing maintenance from IT staff. When the source system updates, the integration needs attention. When a new entity is added, the import process needs to be extended. That maintenance consumes 2 to 4 FTEs worth of IT capacity at most mid-market hospitals. Capacity that could be directed toward cybersecurity, clinical systems, or the digital transformation initiatives the board keeps asking about.

What DSD Sees in the First Conversation

Across dozens of healthcare implementations, the pattern is remarkably consistent. Organizations know the manual import burden exists. They feel it every month. But they have rarely quantified it.

The first step in any engagement with DSD is a diagnostic conversation that maps these workflows in your specific environment. How many data sources feed your GL? How does data move between them? Where are the manual steps, and how many hours do they consume? What breaks most often, and what does it cost when it does?

The answers are always more than people expect. Not because the team is inefficient. Because the system forces them to be the integration layer that the technology should be providing.

DSD’s consulting team includes professionals who held Controller, Director of Finance, and VP of Accounting roles at healthcare organizations before joining DSD. They have personally sat through these import cycles. They know what the manual process feels like, not just what the automated alternative looks like. That is a different kind of implementation conversation.

Start the Conversation

If your finance team is spending 20+ hours a month on manual data imports, the math on eliminating that burden is straightforward. The question is not whether it is worth fixing. It is how quickly you can get from where you are to where the data flows without your team hand-carrying it between systems.

DSD can walk you through what that transition looks like for your specific environment: your EHR, your payroll platform, your entity structure, your current import workflows. Not a demo. A diagnostic.

See what your team could do with 20 extra hours per month.

Schedule a consultation here.

Douglas Luchansky

Director, Client Transformation

Want to learn more about Cloud ERP?

Contact us or check out our resource center!

You’ve Heard a Lot About AI. Here’s What It Can Look Like in Sage 100

DSD Business Systems and Endpoint Automation Solutions Deepen Strategic Partnership to Advance Manufacturing Solutions for the Sage 100 Community

What Healthcare Finance Teams Should Budget for in an ERP Migration

The post 20+ Hours of Manual Imports, Gone: What the EHR-to-GL Workflow Looks Like After Cloud Migration appeared first on DSD Business Systems.

Open APIs for EHR Integration: How Cloud ERP Eliminates Integration Spaghetti

DSD Business Systems — Tue, 26 May 2026 23:11:31 +0000

Every hospital CIO knows the feeling. You open a ticket queue on Monday morning and half the issues trace back to the same root cause: data did not get from System A to System B the way it was supposed to.

A batch file from the EHR failed silently overnight. The payroll integration dropped records because someone changed a field format on the source side. The AP automation tool sent duplicate invoices because the middleware reprocessed a file it had already consumed. The finance team is waiting on data that should have landed hours ago, and your team is debugging plumbing instead of building capability.

This is integration spaghetti. It is the defining infrastructure problem for mid-market hospital IT departments. And it is the single largest reason CIOs hesitate when finance leaders ask about ERP modernization: the current system is fragile, but at least the integrations work (most of the time). Starting over feels like rebuilding the spaghetti from scratch.

It does not have to be that way. The difference between legacy integration architecture and API-native integration is not incremental. It is structural. And understanding that difference is the key to evaluating whether a modern financial platform will actually reduce your integration burden or simply relocate it.

The Legacy Integration Stack: How We Got Here

Most mid-market hospital IT environments did not plan their integration architecture. It accumulated.

The EHR was the first system. Then came the financial platform. Then payroll. Then AP automation. Then revenue cycle management. Then a planning tool. Then a donor management system for the foundation. Each one needed data from at least two other systems, and each integration was built to solve an immediate problem with the tools available at the time.

The result is a patchwork of integration methods, each with its own failure modes:

Flat file exports

The oldest and most common approach. System A generates a CSV or fixed-width text file on a schedule (nightly, weekly). System B picks up the file from a shared directory or SFTP server and imports it. The file format is rigid. If the source system changes a column header, adds a field, or modifies a date format, the import breaks. Silently. You do not find out until someone notices the numbers are wrong.

Scheduled batch jobs

A step up from flat files. A database query runs on a schedule, extracts data from the source system, transforms it into the target format, and loads it into the destination. These jobs run overnight or on weekends. When they fail, the failure shows up as a gap in the next morning’s data. Troubleshooting requires someone who understands both the source and target data models, which is usually one person on your team.

Custom middleware

For more complex integrations (especially between the EHR and financial system), many organizations have deployed middleware platforms: MuleSoft, Boomi, Microsoft BizTalk, or a homegrown integration engine. The middleware handles data transformation, routing, and error handling. In theory. In practice, the middleware becomes its own maintenance burden. It requires specialized skills to configure and troubleshoot. It adds a layer of complexity between every system pair. And it needs to be updated whenever either the source or target system changes its data model.

Point-to-point connectors

Some vendors offer pre-built connectors between specific systems (e.g., an EHR-to-ERP connector). These work well when they work. The problem is lifecycle management. When the EHR vendor releases a major update, does the connector vendor update in lockstep? Or does your team discover on go-live day that the connector is broken and the vendor is “working on a fix”?

Each of these approaches shares a fundamental problem: they are brittle. They depend on static data formats, predictable schedules, and systems that do not change. In a healthcare IT environment where the EHR alone releases major updates quarterly, “systems that do not change” is a fiction.

The Cost of Integration Spaghetti

The cost is not just the time your team spends fixing broken integrations. It compounds across multiple dimensions.

IT capacity drain

At most mid-market hospitals, 2 to 4 IT staff members spend a significant portion of their time maintaining ERP-related integrations. Patching middleware, rebuilding flat file mappings, monitoring batch jobs, and troubleshooting failures. This is not strategic work. It is maintenance that consumes capacity your team could direct toward clinical systems, cybersecurity, or digital transformation initiatives.

Finance team delays

When an integration fails, the finance team waits. They wait for data from the EHR. They wait for payroll allocations. They wait for AP data to reconcile. Every integration failure adds hours or days to the close cycle. And because finance teams learn not to trust the automated data, they build manual verification steps into their workflow. Those steps become permanent even after the integration is fixed.

Audit exposure

Flat file integrations and batch jobs create gaps in the audit trail. When data moves between systems via file transfer, the lineage is difficult to trace. If an auditor asks how a specific charge from the EHR became a journal entry in the GL, your team may need to reconstruct the path through multiple files, transformation scripts, and manual adjustments. That reconstruction takes time and introduces risk.

Upgrade paralysis

The most insidious cost is the one you do not see: upgrades that never happen. When every system is connected to every other system through fragile integrations, upgrading any single system feels risky. Your EHR team wants to move to a new version, but the financial integration might break. Your finance team wants a modern platform, but rebuilding 15 integrations feels overwhelming. The result is stasis. Every system stays on its current version because no one wants to be the first domino.

API-Native Architecture: A Different Approach

A cloud-native financial platform built on open APIs changes the integration model fundamentally.

APIs are real-time, not batch:

Instead of waiting for a nightly file export, an API connection delivers data as events happen. When a charge posts in the EHR, an API call can create the corresponding financial transaction immediately. No waiting. No batch windows. No gaps.

APIs are self-documenting:

A well-designed REST API publishes its own documentation: endpoints, data formats, authentication methods, error codes. When the financial platform updates its API, the documentation updates automatically. Developers (and increasingly, integration platforms) can inspect the API to understand what data is available and how to access it.

APIs handle errors explicitly:

When an API call fails, it returns a specific error code and message. Your monitoring tools can catch these in real time. Compare this to a batch file that fails silently and a team that discovers the gap two days later.

APIs enable bidirectional data flow:

Legacy integrations are typically one-directional: data flows from the EHR to the financial system, period. APIs enable bidirectional exchange. The financial system can query the EHR for clinical volume data to inform budget models. The planning tool can push approved budget figures back to departmental systems. Data flows where it is needed, when it is needed.

What This Looks Like in a Healthcare Environment

A cloud-native financial platform built on open APIs changes the integration model fundamentally.

Legacy approach:

The EHR generates a nightly batch file containing charges, payments, and adjustments. The file lands in a shared directory. A scheduled job picks it up, reformats the data to match the GL structure, maps charge codes to GL accounts, and loads the transactions. If the file has errors (and it will), the import fails. Someone investigates the next morning. The failed records get corrected and re-imported manually. Finance sees yesterday’s data by midmorning, if nothing went wrong overnight.

API-native approach:

The EHR posts events to the financial platform’s API as transactions occur. Charge code mapping is defined once in a configuration layer (not in a transformation script). New charge codes are flagged automatically for review instead of causing a silent import failure. The financial platform reflects clinical activity in near real-time. Exceptions are surfaced immediately through system alerts, not discovered the next morning by a staff member checking a log file.

The same pattern applies to payroll integration, AP automation, revenue cycle data, and supply chain. Each integration becomes simpler, more reliable, and more maintainable when built on APIs instead of file-based batch processes.

The CIO's Evaluation Checklist for ERP Integration

When evaluating a new financial platform, the integration architecture deserves as much scrutiny as the financial features. Here is what to assess:

API coverage:

What percentage of the platform’s functionality is accessible via API? If the answer is “most, but not the consolidation module” or “everything except custom reports,” the API is incomplete.

API documentation:

Is the API documentation public and up to date? Can your team (or a systems integrator) inspect endpoints, test calls, and build integrations without waiting for the vendor to provide specifications?

Healthcare-specific connectors:

Does the vendor or its partner ecosystem offer pre-built connectors for major EHR platforms (Epic, Cerner, athenahealth, eClinicalWorks, NextGen)? Are these connectors maintained and updated in step with EHR releases?

Webhook and event support:

Can the platform push notifications to other systems when events occur (e.g., a journal entry is posted, a consolidation is complete, a budget is approved)? Event-driven architecture reduces the need for polling and batch jobs.

Error handling and monitoring:

How does the platform surface integration errors? Are there built-in dashboards for monitoring API call volumes, error rates, and latency? Can your team set up alerts for specific failure conditions?

Authentication and security:

Does the API support modern authentication standards (OAuth 2.0, API key management, IP whitelisting)? How does the platform handle PHI in transit? Is the API connection HIPAA-compliant?

Marketplace breadth:

How many third-party integrations are available in the vendor’s marketplace? Are healthcare-specific integrations (EHR, payroll, revenue cycle, supply chain) well-represented, or is the marketplace dominated by generic business tools?

Why This Matters for the CIO's Capacity Argument

If you are a CIO or VP of Applications evaluating ERP modernization, the integration architecture is your strongest internal argument.

Your team’s time is finite. Every hour spent maintaining a flat file integration or debugging middleware is an hour not spent on cybersecurity, clinical systems optimization, or the digital transformation initiatives your board is asking about. Integration maintenance is invisible work. It does not show up in a project portfolio. But it consumes real capacity from real people, every week.

Moving to an API-native financial platform does not eliminate all integration work. But it changes the nature of that work from reactive maintenance (fixing broken batch jobs) to proactive configuration (defining data flows that handle changes gracefully). That is a fundamentally different use of your team’s skills and time.

And when the finance team’s next EHR upgrade does not break the financial integration, the CIO who made that possible has demonstrated something concrete: the modernization investment is paying off in reduced operational risk, not just in feature improvements.

Start the Conversation

DSD Business Systems is a Sage Intacct implementation partner that brings a unique perspective to healthcare ERP integration. Our consulting team includes professionals who understand both the financial platform and the healthcare operational environment: the EHR workflows, the clinical data models, the regulatory requirements, and the IT constraints that shape integration decisions.

If integration complexity is the reason your organization has not moved forward with ERP modernization, we should talk. Not about features. About architecture, and what it would take to replace your integration spaghetti with something your team can actually maintain.

See what clean EHR integration looks like.

Schedule a consultation.

Douglas Luchansky

Director, Client Transformation

Want to learn more about Cloud ERP?

Contact us or check out our resource center!

You’ve Heard a Lot About AI. Here’s What It Can Look Like in Sage 100

DSD Business Systems and Endpoint Automation Solutions Deepen Strategic Partnership to Advance Manufacturing Solutions for the Sage 100 Community

What Healthcare Finance Teams Should Budget for in an ERP Migration

The post Open APIs for EHR Integration: How Cloud ERP Eliminates Integration Spaghetti appeared first on DSD Business Systems.

Top DSD Enhancements That You May Not Know About

Tamara Nenninger — Fri, 22 May 2026 21:26:37 +0000

DSD Business Systems has developed hundreds of Enhancements to Sage 100 over the last 40 years, including widely used solutions such as Multi-Currency, InstaDocs, Service Center, and DSD/ScanForce Multi-Bin. There are many DSD enhancements that are excellent solutions, but may not be well known to Sage 100 end-users.

In this 2-part series, I will present 20 DSD Enhancements that you may not be aware of, but are perfect for any organization looking to boost their Sage 100 experience though streamlining and enhanced functionality.

Here are my first 10 Solutions that are high-value enhancements to your Sage 100 system:

Top DSD Enhancements that
you may not know about

1. APGC Auto Check Payment Generation

In Vendor Maintenance / Invoices tab, you now have the ability to select multiple invoices and generate a check payment entry by right clicking and selecting “Generate Check Payment” or pressing the new green dollar sign.

All invoices selected on the Invoices tab will be auto paid in full.

Visit APGC >>

2. ARGR Auto Generate Cash Receipts

Similar to the APGC Auto Check Payment Generation listed above, this DSD Enhancement allows for quick Cash Receipts of an invoice. In Customer Maintenance / Invoices tab, you now have the ability to select multiple invoices and generate a cash receipts entry by right clicking and selecting “Cash Receipts Generation” or pressing the new green dollar sign.

Visit ARGR >>

3. ARCC Credit Collections

The ARCC Customer Collections enhancement is designed for those companies that need to track collection history and call history by Customer. Call Codes may be setup and assigned on First, Second, Third, and Final collection call attempts. You can track Collection History, print Call Lists and Collection Letters, and use the Customer Collection dashboard to view and update call history.

Additional Features include:

Define Past Due Threshol by Customer
Assign Collection Users to Customers
Dashboard displays which assigned customers are past due
User-defined Collection Call Codes
Maintain Info on Call Attempts
Call List Printing
Collection Letter Printing
Credit Hold Utility
Cash Receipts Update to remove Credit Hold

Visit ARCC >>

4. ARBE Paperless Delivery Use Bill-To Customer Email Address

Paperless Office Delivery Options in Customer Maintenance has been enhanced to include a new option “Use Bill To Customer Email Address”. This option is only enabled if the “Enable Bill To Customer Reporting” feature has been enabled in A/R Setup Options. The Bill-To Customer’s email address will be used for all associated Sold-To Customer invoices.

Visit ARBE >>

5. ARST Service Trade Integration

This DSD enhancement is an integration between Sage 100 and Service Trade, using a REST API protocol. It’s the perfect solution for users that do field service and use technicians to service their products at the customer locations. There are two major features in this integration:

Customer, Ship-To, and Item Code information is synchronized from Sage 100 to Service Trade real-time. This means that any addition, change, or deletion of a Customer, Ship-To, or Item will automatically synchronize to the Service Trade system.
Sage 100 S/O Invoices can be generated from the download of Service Trade invoices.

Both Regular Items and Miscellaneous Items can be “flagged” as Service Trade items, and will be included in the synchronization. Customers can be “flagged” as Service Trade Customers, and will be included in the synchronization, along with associated Ship-To Codes.

For more information on the Service Trade, please visit: https://servicetrade.com

Visit ARST >>

6. BMPD Production Lot/Serial Distribution

This DSD Enhancement to the Bill of Materials module adds the ability to assign multiple unique lot/serial numbers on the Product Entry Header. Standard Sage 100 only allows the entry of a Starting Serial Number or the production of a single Lot Number in an entry. This enhancement adds a Lot/Serial Distribution on the Production Entry Header for Lot/Serial Bills so that you can produce multiple Lot/Serial numbers in a single entry.

Visit BMPD >>

7. CIPL Paperless Delivery From User

The DSD Enhancement enhances the Paperless Office Electronic Form Delivery process to allow you to assign the “From” Email Address as defined in User Maintenance for the Sage 100 User performing the printing task.

Visit CIPL >>

8. BRTH Bank Reconciliation Transaction History

The B/R Transaction History enhancement allows Bank Reconciliation transactions, such as Checks, Adjustments, and Deposits, to be stored in a History File during the Purge process. Standard Sage 100 allows for purging of Bank Reconciliation transactions after the Bank Reconciliation Report is printed. Once this purge occurs, those transactions are no longer retained. With this enhancement, the purging process moves the transactions to a history file for future access.

A new B/R Transaction History Inquiry has been added to the B/R Main Menu. This Inquiry panel displays all transactions that are moved to history. The fields displayed on this History Inquiry Panel are identical to the fields displayed in Check, Deposit and Adjustment Entry, along with two new fields: Purge Date add Purge User (the user that ran the purge process).

Additional features include:

The user has the ability to “Restore” from history back into the Checks, Adjustments, and Deposit file. This allows the user to re-reconcile if a mistake was made.
A Bank Reconciliation History Report is available to print from the new B/R Transaction History file.
A Bank Reconciliation By Date Report is available, that allows the user to print a Bank Reconciliation Report based on a historical date.

Visit BRTH >>

9. CMAF Cash Management and Forecasting

Cash Management and Forecasting is ideal for Cash Flow analysis, modeling and reporting. Sage 100 users now have the ability to define how the performance measurements are taken. Complete payment performance reviews for all customers and vendors, while also developing more precise cash predictions based on actual payment history, rather than payment terms. Features include:

Integrates with Sage 100 Accounts Receivable, Accounts Payable, Inventory Management, Sales Order Processing, Purchase Order Processing and Payroll Processing.
Perform payment performance reviews for all customers and vendors, and develop more precise cash predictions based on actual payment history, not on payment terms.
Create expense and revenue projections by using historic seasonal fluctuations in product lines, products sold and recurring expenses such as utilities.
Build cash flow models that may be “exploded” to create projected cash flow analyses on demand.

Visit CMAF >>

10. EMEM Equipment Maintenance

The Equipment Maintenance Module keeps your company up to date with the equipment it takes to operate your business on a day-to-day basis. Equipment Maintenance allows you to track maintenance tasks and assign items to these tasks, while tracking technician’s labor and time to complete tasks.

Visit EMEM >>

What’s Next

These enhancements represent just a portion of the powerful tools available to help you get more out of your Sage 100 system. Each solution is designed to streamline processes, improve visibility, and increase overall efficiency across your organization.

Stay tuned for Part 2 of this series, where we’ll highlight 11 more valuable DSD Enhancements that can further elevate your Sage 100 experience and help you unlock even greater productivity.

Jon Reiter

General Manager, Sage 100 Enhancements

Want to learn more about DSD Enhancements?

Contact us or check out our resource center!

Integrate your Sage HCM Payroll with Sage 100

The post Top DSD Enhancements That You May Not Know About appeared first on DSD Business Systems.

Blog – DSD Business Systems

You’ve Heard a Lot About AI. Here’s What It Can Look Like in Sage 100

Sage AI Help Agent can help answer, How do I complete a specific task in Sage 100?”

Phocas BI can help answer, “What is happening in my business, and how is performance changing across key areas?”

ConverSight can help answer, “What trends, patterns, and forward-looking insights can AI identify to support decisions?”Together, these tools show what AI and intelligent technology can look like in a modern Sage 100 environment.

AI Is Becoming Practical for Sage 100 Users

What Is Sage AI Help Agent?

What Sage AI Help Agent Does Not Replace

Sage AI Is the Beginning of a Smarter Sage 100 Environment

How Phocas BI Enhances Sage 100

What Phocas BI Can Add to the Sage 100 Experience

How ConverSight Further Extends AI for Sage 100

ConverSight supports AI-assisted analysis and planning

What a Smarter Sage 100 Platform Can Look Like

It can mean sales leaders receiving clearer visibility into customer and product performance.

It can mean finance spending less time rebuilding reports.

It can mean users finding product guidance without leaving Sage 100.

It can mean inventory teams identifying demand changes and potential issues earlier.

It can mean leadership receiving more timely insight instead of waiting for another spreadsheet to be prepared.

AI in Sage 100 Is About Better Access to Answers

Want to learn more about Sage 100? Contact us or check out our resource center!

RELATED SAGE 100 posts

Healthcare ERP Modernization: Building the Business Case for Your Board

The Four Pillars of the Case

Pillar 1: Margin Improvement Through Decision Velocity

Pillar 2: Risk Reduction in Financial Reporting

Pillar 3: IT Capacity Recapture

Pillar 4: Audit and Compliance Efficiency

Building the Board Outline

The Question Behind the Questions

What DSD Sees in Cases That Hold Up

A Final Note for CFOs at This Stage

Start the Conversation

Douglas Luchansky

Want to learn more about Cloud ERP? Contact us or check out our resource center!

RELATED SAGE posts

SaaS vs. On-Premise ERP for Mid-Market Hospitals: A Rigorous TCO Comparison

The Comparison Most Boards See, and Why It Fails

The Categories That Belong in the Model

Category 1: Software Licensing

Category 2: Infrastructure

Category 3: IT Labor

Category 4: Implementation

Category 5: Integration

Category 6: Customization and Reporting

Category 7: Training and Change Management

Category 8: Risk and Compliance

Category 9: Opportunity Cost

Putting It Together: A Five-Year Range

Where On-Premise Still Wins

Where SaaS Wins by a Margin That Should Move the Decision

Using This Model in the Capital Committee

Start the Conversation

Douglas Luchansky

Want to learn more about Cloud ERP? Contact us or check out our resource center!

RELATED SAGE posts

DSD Business Systems and Endpoint Automation Solutions Deepen Strategic Partnership to Advance Manufacturing Solutions for the Sage 100 Community

11 Signs Manufacturers Need an Integrated Cloud ERP in 2026

The 11 warning signs for manufacturing ERP evaluation

What are the operational warning signs that signal you’ve outgrown basic software?

When should manufacturers start evaluating additional ERP options?

Start your evaluation when you notice any of these patterns:

Your finance team spends more time gathering data than analyzing it

Operations staff have created personal systems (spreadsheets, notebooks, whiteboards) to track what the software misses

You’ve delayed adding products or locations because your systems can’t handle the complexity

Why Acumatica is The Solution for Manufacturers

Here’s what we evaluated:

Why DSD is a standout Gold Certified Acumatica Cloud partner for manufacturers

FAQs about manufacturing ERP for growing businesses

What’s the difference between accounting software and manufacturing ERP?

Can I keep using QuickBooks alongside manufacturing ERP?

What training do my employees need for manufacturing ERP?

How does DSD Business Systems support manufacturers after go-live?

Final Thoughts: How does DSD Business Systems support manufacturers after go-live?

Want to learn more about Acumatica? Contact us today!

RELATED Acumatica posts

What Healthcare Finance Teams Should Budget for in an ERP Migration

What is this actually going to cost us?

How much should we budget total for an ERP migration?

What is the typical split between platform cost and implementation cost?

Want to learn more about Sage 100?

Contact us or check out our resource center!

Want to learn more about Cloud ERP?

Contact us or check out our resource center!

Want to learn more about Cloud ERP?

Contact us or check out our resource center!

Want to learn more about Acumatica?

Contact us today!

Want to learn more about Cloud ERP?

Contact us or check out our resource center!