Feature parity with Word and Excel

Nobody has full parity with Word and Excel except Microsoft Office itself. A promise of “feature parity” without qualification means nothing and can’t be verified. That’s why parity is broken down into tiers—and at every tier there’s a way to check on your own files.

Tier	What it means	How it’s proved
By scenario	The user performs their everyday actions without switching to Microsoft Office.	An agreed acceptance scenario inside your application.
Format openability	DOCX, XLSX, XLSB, ODS and CSV open in the chosen runtime. Opening isn’t the same as editing and saving: these are separated by row—spreadsheet formats, what you can do with each file in documents.	Open the entire agreed set of documents and review every warning and refusal.
The editing corridor	The agreed capabilities work correctly: text, tables, formulas, formatting, comments, sheets, charts.	Compare the document’s meaning before and after editing, for every capability on the list.
Save	A saved file reopens without losing its meaning or structure.	Reopen it in a new process, ideally twice, and separately verify the “saved here, opened in Word or Excel” round trip.
Preservation of the unsupported	What the editor doesn’t understand is preserved unchanged, or explicitly flagged.	Compare the file’s contents before and after, including the relationships between parts.
Automation	Macros, queries, and agents work within the supported subset; everything else is recognized and explained.	A capability matrix, explicit refusals instead of silent errors, an action log.
Operations	Offline operation, on-premises installation, security, updates, and the lifecycle meet enterprise deployment requirements.	A security checklist, full resource release on shutdown, the delivery inventory and signatures — what’s already there today is listed in Risks.

What’s promised

SumOffice provides an embeddable platform on par with Word and Excel, with parity over an agreed set of documents and a capability profile. In specific respects — embedding into someone else’s product, manageability, explicit refusals, preserving unsupported markup, readiness to work with agents — the platform can be stronger than familiar office suites, even without replicating every Microsoft Office feature.

Why this is stronger than the usual “we support XLSX/DOCX”

• What matters to the customer isn’t a list of file extensions, but that nothing was lost after saving.
• What decides a migration are the specifics: data queries, macros, links to other workbooks, charts, pivot tables, styles, comments, tracked changes, headers and footers, and fields.
• Whoever embeds the editor in their product cares about more than looks: the lifecycle, memory consumption, full resource release on shutdown, update compatibility and observability.
• The capability matrix turns an argument into a verifiable agreement: what is read, what is edited, what is saved, what is preserved as-is without parsing, and what is rejected.

The matrix doesn’t use free-form language. The spreadsheet delivery contains a closed list of eight states, and every cell gets one of them:

State	What it means
Absent	This part wasn’t present in the workbook under test.
Not documented	This part is on the list, but the product can’t recognize it yet — and doesn’t pretend that it can.
Detected, not interpreted	Its presence is detected, but the product doesn’t assign it meaning and doesn’t promise to preserve it.
Preserved only	The part passes through open and save as opaque data: it won’t be lost, but it won’t be understood either.
Cached value only	What’s shown is whatever Excel wrote; the product doesn’t promise a live recalculation.
Partial	There’s live behavior, but coverage is narrow, and that’s stated outright.
Blocked by policy	The part is recognized, but running it is deliberately blocked — by a product rule or a security policy.
Fully live	Its meaning is modeled and kept live, without relying on cached values.

The difference between “preserved only” and “cached value only” is the boundary people usually argue about: in the first case the part of the workbook comes back unchanged, in the second you’ll see a number, but it wasn’t recalculated by us.

A state is assigned not to the workbook as a whole but to its parts. The list of parts is closed too—ten families:

Workbook part	What it includes
Macros	Automation built into the workbook: VBA and the like.
Add-ins	Functions and commands that come from add-ins.
External data	Connections and refreshable queries.
External references	References to other files and workbooks.
Names and hidden dependencies	Named ranges, hidden areas—everything that affects the workbook’s meaning without appearing on screen.
Tables	Structured tables, their styling and behavior.
Pivots and the data model	Pivot tables, their caches, slicers and the data model.
Protection and trust	Protection flags and parts restricted by trust rules.
The import/export round trip	Parts where what matters isn’t behavior but import accuracy and preservation on export.
Provenance and diagnostics	Parts that explain why content was preserved as-is, blocked, or shown from a cache.

The matrix is the intersection of the two lists: every workbook part has its own state. The question “do you support macros” turns into “what state do macros have in my workbooks”, and that one has a verifiable answer.

What to measure with

• 41 commands of the SumDoc document session—for developers: Session Protocol reference.
• 208 operations in the SumSheet contract; which of them the core of the latest release accepts is stated in the Compute Contract reference. Take the release as the yardstick for acceptance: what is described but not yet in the build can’t be verified on your workbooks.
• What’s available today, and what’s part of the pilot — SumDoc readiness and boundaries and SumSheet strengths and trade-offs.