How to Build Excel Report Output - COM / Open XML / Templates

In consultations about Excel report output, the phrase “we want to output to Excel” often turns out to contain several distinct requirements mixed together.

• Users want to edit the output by hand afterwards
• An existing .xlsm needs to be kept
• Pivot tables, charts, and print settings should carry over as is
• Large volumes need to be produced by a nightly batch
• It must run unattended on a server
• A PDF is also wanted

No single approach solves all of these cleanly. The first thing to look at is not the library name but whether you are driving the Excel application or building an Excel file.

Get this wrong and things may work at first, but maintenance becomes painful later. In this article, assuming Excel report output in Windows apps and business systems, we organize how to choose among COM automation / Open XML / template-based data injection / coexisting with existing VBA.

1. Conclusions First

Let us lay out the conclusions up front.

• If the report is one that users will open and edit in Excel afterwards, the first candidate is a template plus direct .xlsx / .xlsm generation.
• If you generate automatically on a server / service / scheduler, it is safer not to base the design on Office automation.
• If you want to leverage existing .xlsm files, VBA, charts, pivot tables, and print settings, the design is more robust if you push layout and Excel-specific features into the template and keep the code focused purely on data injection.
• Only when you truly need the behavior of the Excel application itself is it natural to use COM automation, and even then limit it to attended execution on the desktop.
• If you just need a plain list export, CSV / PDF / a web page quite often fits the requirements better from the start.

In short, for many business reports it is more natural to “assemble an Excel file” than to “operate Excel”.

2. What to Decide First

Here is a table of the things you want to decide first for Excel report output.

3. Main Implementation Approaches

3.1 Excel COM Automation

This approach launches Excel and manipulates Workbook, Worksheet, and Range via COM. It is easiest to understand as driving the real Excel.

Its strength is that you can use Excel-specific behavior as is. It plays well with existing workbooks, charts, pivot tables, print settings, macros, and PDF export, and lets you work directly with “how Excel will ultimately present it.”

Its weaknesses, however, are equally clear.

• Excel must be installed
• You take on process lifetime, file locks, dialogs, bitness, and user-profile dependencies
• Office Automation from an unattended server or service is something Microsoft itself does not recommend or support

3.2 Direct .xlsx Generation

Since .xlsx is the Open XML format, you can assemble files directly without launching Excel. With tools like the Open XML SDK, your program can manipulate workbooks, sheets, cells, styles, and tables.

The strength of this approach is that it is easy to run in environments without Excel installed and pairs well with batch jobs and servers.

On the other hand, things get harder when you want to naturally reproduce the UI-oriented behavior that Excel itself provides. Auto-fitting column widths, page breaks, complex visuals, and deep editing of existing workbooks quickly turn into a slugfest if you try to do all of it cleanly in code alone.

3.3 Template-Based Data Injection

The approach we find easiest to recommend in practice is to create an Excel template first and keep the code focused purely on data injection.

The report’s appearance, formulas, conditional formatting, print areas, headers / footers, logos, and charts live in the template. The code copies the template and writes data into agreed entry points: named ranges, tables, cell ranges, and so on.

Doing this separates layout changes from business-logic changes. It goes a long way toward avoiding the Cells[37, 9] = ... hell so common in Excel reporting.

3.4 Keeping Existing VBA Assets

If existing .xlsm files or VBA are alive and well, it is often more natural not to rebuild everything at once. Leaving the report UI and final formatting in VBA while moving heavy computation and DB / HTTP / business logic to the C# / .NET side is a very realistic split.

What matters here is not leaving responsibilities ambiguous.

• The VBA side owns behavior inside the workbook
• The .NET side owns data retrieval and business processing
• The boundary between them is fixed via named ranges, tables, public interfaces, and the like

3.5 Cases for Microsoft 365 / Graph

If the Excel files live on OneDrive / SharePoint from the start and you want to share them from web or mobile apps, the Microsoft Graph Excel API is also an option.

It is not, however, a general-purpose answer for casually mass-producing arbitrary files on a local PC. Permissions, storage location, sessions, and operations all assume M365 from the outset.

3.6 Does It Need to Be Excel at All?

If the requirement is “a table people will work with afterwards,” choosing Excel is natural. But for requirements like these, another format is often the more straightforward choice.

• Printed and archived -> PDF
• Imported into another system -> CSV / TSV / JSON
• Only needs to be viewable in a browser -> HTML / web page
• Aggregation and visualization are the main goal -> BI or a dashboard

4. Comparing the Approaches

Putting the differences side by side in one table gives this.

5. Choosing by Common Requirements

5.1 Output on the User’s PC, Then Edited Directly

In this case, template plus direct generation is a very strong choice. Users open the output in Excel afterwards, so the final editing can simply be left to Excel.

5.2 High-Volume Generation in a Nightly Batch or Service

If a nightly batch is involved, it is safer to start by ruling out COM automation. Move generation to direct .xlsx creation, and if needed, let users open the files in Excel afterwards.

5.3 Leveraging Existing .xlsm / VBA

If existing assets are still alive, the realistic path is to keep the .xlsm as the template and perform only the data injection from outside.

5.4 Large Detail Row Counts

The limit for a single Excel sheet is 1,048,576 rows by 16,384 columns. When detail data is large, decide these points first.

• Above how many rows do you split into multiple sheets?
• Above how many records do you split into multiple files?
• Would CSV be the more natural choice in the first place?

6. An Architecture That Is Easy to Recommend in Practice

What proves robust in practice is an architecture split into four layers.

The nice thing about this split is that the code becomes much less likely to be dragged around by Excel’s appearance.

7. Pitfalls

7.1 Do Not Turn Cell Addresses into Business Specifications

Once Cells[12, 7] starts representing a business rule, a layout change becomes a spec change. Code lasts longer when it touches the report through named ranges and table names.

7.2 Do Not Use Merged Cells as Data Entry Points

Merged cells are a presentation feature. Using them as injection targets makes accidents likely when adding rows or computing ranges.

7.3 Do Not Fill Numbers and Dates as “Pre-Formatted Strings”

It is more natural to store values as values and push appearance into cell formats.

7.4 Do Not Let Template Changes Go Unmanaged

A template is not code, but in practice it is the specification itself. The safe approach is to treat it as subject to version control, diff review, and code review.

7.5 If You Use COM, Do Not Underestimate Bitness and Lifetime Management

With COM automation and VBA integration, 32-bit / 64-bit differences, Excel process cleanup, file locks, and differences across user environments quietly take their toll.

8. Summary

Excel report output looks like a one-line topic—”output to Excel”—but in reality several decisions need to be made up front.

• Are you driving the Excel application?
• Are you building an Excel file?
• Does it run on the user’s PC, or unattended?
• Will existing VBA or .xlsm files be kept?
• Is the final deliverable Excel, or PDF / CSV?

As a first candidate in practice, template plus direct generation is very strong. Adding reuse of existing VBA or final Excel processing on the user’s PC to that as needed tends to come together well.

9. References

• Considerations for server-side Automation of Office
• Considerations for unattended automation of Office in the Microsoft 365 for unattended RPA environment
• About the Open XML SDK for Office
• How to: Copy a worksheet with SAX (Simple API for XML)
• Overview of the Excel workbooks and charts API - Microsoft Graph
• Access OneDrive and SharePoint via Microsoft Graph API
• Excel specifications and limits

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.