Capability map next to Excel

What in SumSheet is described by contract and verifiable, how it differs from Excel, and what we don't claim.

SumSheet gets compared with a spreadsheet editor, and at that level all the contenders look the same: a grid, formulas, formats. The difference begins where the spreadsheet stops being a separate application and becomes part of someone else’s product. This page answers one question: of what you’re used to from Excel, what SumSheet has, what it has partially, and what it doesn’t have.

There’s no claim here that “we’re better”. Excel remains the benchmark for completeness of spreadsheet semantics: it has native Power Query, the M language, VBA, and an object model. What’s shown below is something else — which layers of SumSheet are described by contract, and are therefore verifiable against your own files.

The marks in the table refer to the contract. The contract and a published release aren’t the same thing: some of the described operations haven’t made it into a build yet, and wherever that affects a row below, it says so directly in it. The full difference is in the reference.

We write “no” about Excel only where there’s a source and a verification date. Where there’s no solid source, it says “needs verification”: check for yourself, links are at the bottom of the page.

Legend

Mark	What it means
●	Yes: covered by operations of the published release and checked on every documentation build
◐	Partial: the mechanism is ours, but it doesn’t replicate someone else’s one to one; the row says exactly how it differs
◇	Not locked in: the mechanism works, but there’s no public set with stable names and versions for it yet — you can build on it, but you need to know that in advance
—	No: no native equivalent was found in the official documentation
?	Needs verification: we don’t have a solid source yet

We don’t paint anything from “partial” or “not locked in” with the green “yes” mark. A dash means exactly what it says: no native capability was found in the official Microsoft documentation we studied. That’s not proof it can’t be added with an add-in. If you know a source that refutes any cell, write to us — we’ll correct it and update the date.

Comparison by capability

Capability	SumSheet	Excel	What’s behind it
Tables and formulas	●	●	The base level; by itself it doesn’t set one product apart from another. The substantive conversation starts with the list of functions, and SumSheet has one: the delivery includes a registry of 508 functions — one entry per name — and each records which section it belongs to, at which delivery stage it will work, and which checks cover it. It’s not a list of what’s supported: the number of functions verified against Excel by value is always smaller than the number of entries in the registry. Ask about your own stage; the list is right there.
Excel formats	●	●	SumSheet has a declared capability matrix and a rule for preserving what the editor doesn’t understand.
Pivot tables	●	●	Eleven contract operations: calculated fields and items, grouping and drill-down, layout, filters and ranking, value field settings, report filter pages. The OLAP data model is available read-only.
Conditional formatting	●	●	Rules are applied, changed, and moved between ranges by three contract operations; the core of the latest release accepts all three.
Protecting the workbook, sheet, and ranges	●	●	Six operations: permissions on individual ranges, sheet protection, the workbook protection lifecycle, showing exactly what protects the file, and opening a password-protected workbook — by path and from passed bytes.
Power Query	◐	●	Connecting, transforming, merging, loading, and refreshing — within a declared subset. The contract doesn’t promise full parity with Excel: that’s stated in it as a separate line.
The M language	◐	●	Parsing and evaluation happen in the Rust core with its own function library. This is a subset of the language, not a full M runtime.
Query dependencies and refresh	●	●	A dependency graph, cancellation, and preempting a stale refresh.
Query privacy and credentials	●	●	Source privacy levels; secrets never end up in the workbook’s projections.
Running VBA macros	◐	●	A macro is never executed in the workbook itself: the core inspects the project, plans the run, executes the macro on a copy, shows a preview of the changed cells, and carries the result over only after confirmation; rollback is available. The macro is executed by SumSheet’s own runtime in Rust, in a declared subset of the language — the run plan says exactly what’s included (VBA and macros).
The Excel object model	●	●	In SumSheet, the runtime is separate from the object model layer.
Workbook and sheet events	●	●	The mechanisms differ; Excel’s event semantics have to be reproduced separately.
Forms and the interaction model	●	●	In SumSheet, the model is semantic, not a pixel-for-pixel copy of Excel’s forms.
COM, OLE, ActiveX, Win32	◐	●	In SumSheet this is a compatibility layer with explicit boundaries, not a general Windows environment. A real COM and Win32 (`Declare`) executor exists only in the Windows build. External objects that a macro requests (Scripting.Dictionary, VBScript.RegExp, MSXML, and others per the manifest) are served on every platform by the core’s broker: everything is denied by default, a person grants access to a specific object class and only for a single run, and every call is logged — executed or rejected. For developers: how this is set in the run plan.
Charts	◐	●	The contract covers a chart sheet (creation, print settings, preview) and formatting a chart as a sheet object: template and family, title, legend, labels and data table, axes, series with markers, individual points, trendlines, error bars, and the 3D view of surface charts. Fill and line in the contract are solid color, width, and dash only: gradient, picture, texture, and pattern fills, as well as effects (reflection, glow, soft edges, bevel), are not declared by the contract.
The editor in the browser	◐	●	The core under WebAssembly and the bridge to it ship as SumSheet engine packages — that’s a delivery artifact, not a description. The set of operations is the same as in the desktop app; you build the shell for WebAssembly yourself. A ready-made editor in the browser exists by another route — the web host, where the core calculates on the server and the browser gets the same interface as the desktop app (the server route).
Headless processing	◐	◐	The release core works without an interface: the command-line processor accepts the same contract operations, and that’s what the live example calculates on. The server wrapper around it — queues, quotas, client isolation — you build yourself.
Embedding and OEM	◇	◐	The operations contract and your own shell. Engine packages are delivered, and the embedding examples are built on them, but the public developer kit still isn’t separated from the internal contract: names, versions, and compatibility rules aren’t locked in.
Agents as engine clients	◇	◐	The sequence is explicitly described: inspect, propose, get permission, execute, verify. The release has support for it — an edit preview and a macro run plan among the core’s operations. What’s not locked in is the rest: an agent’s permissions, what goes into the audit, and the approval process — those are pilot territory.

What actually sets SumSheet apart

Data preparation inside the spreadsheet

Power Query in SumSheet isn’t an add-in — it’s a part of the product with its own lifecycle: sources, a query editor with transformation steps, an M language engine, merging, loading the result, a dependency graph, refresh, privacy levels, and credentials. This isn’t “we can open files with queries”, it’s working with queries as objects of the workbook.

Automation as compatibility layers

SumSheet separates parsing the VBA language, the runtime, the Excel object model layer, events, the interaction model, and the boundaries of calling external objects. This lets you say, for any given scenario, what works natively, what works through compatibility, and what isn’t supported at all. The answer “we support VBA” means nothing without this breakdown.

One semantic core for different environments

The desktop app, the browser through WebAssembly, the server wrapper, and agents all call the same operations contract. Spreadsheet semantics aren’t reimplemented for every environment from scratch — and that’s exactly how discrepancies arise, when the same workbook computes differently in different places.

The agent is part of the contract

An agent’s workflow: inspect a bounded state, propose a change, get permission, execute through the contract, verify the result. An agent never becomes a second owner of the document’s meaning, and it never clicks through the interface in place of a person.

What we don’t claim

These four claims shouldn’t be made, either in correspondence or in comparisons — they won’t hold up to scrutiny:

“SumSheet is more complete than Excel.” Excel remains the benchmark for its own semantics, and Power Query, the M language, VBA, and the object model are all native to it.
“We support COM, ActiveX, and Win32.” This layer in SumSheet is marked as compatibility, not a full Windows environment.
“The server platform is ready.” The web host and mobile apps are released, but the wrapper for load — queues, quotas, client isolation — is built separately; where the status is architectural, there’s no finished product.
“Excel doesn’t have this.” If the conclusion rests only on a capability’s absence from the public documentation, that’s not proof.

Where to see the details

How embedding works and what crosses the boundary — Integrating into an application.
Working in the browser — The Web and WebAssembly variant.
The server scenario and its boundaries — SumSheet as a server-side processor.
Strengths and honest tradeoffs — Strengths and tradeoffs.
The full list of operations — the SumSheet reference.

How this table differs from a marketing one

Where Excel is stronger, we say so. A table where the other side looks bad at everything convinces no one and gets debunked in five minutes. Excel is a mature product with forty years of history, and wherever it does more, our column says “partial” or “contract”.

Our column is checked by a machine, not by an editor. Behind every row marked “yes” are operations of the published release: their list is taken from the core itself, and the documentation build checks the text against it and fails if they diverge. So “yes” here isn’t an opinion.

The difference between “yes” and “contract” isn’t a formality. The contract has 208 operations; the published release has 206. Everything that’s described but hasn’t made it into a build yet is marked “contract”, not with the green mark.