ODS

Yes. Microsoft built native ODF support directly into Excel starting with Excel 2007 Service Pack 2, and every version since (2010, 2013, 2016, 365) reads and writes .ods without any add-in. That said, the import filter translates rather than natively renders the format, so complex formulas, pivot tables, conditional formatting, and any embedded macros can shift or fail on open — worth flagging when a DAM ingests ODS assets destined for Excel-only teams.

Yes, with caveats. Because ODS is an open, ISO/IEC 26300-standardized XML container rather than a proprietary binary, templates stored in it stay readable indefinitely regardless of which vendor's spreadsheet app a team standardizes on next — a real advantage for a DAM meant to outlive any single office suite. The trade-off: in Excel-centric organizations, users still expect .xlsx, so a DAM may want to keep both the canonical .ods template and an auto-converted .xlsx copy.

Yes. Because ODS is just a ZIP archive of XML, a DAM can unzip it, parse content.xml with any standard XML library, and read each cell's table:formula attribute as plain OpenFormula-syntax text — no LibreOffice or Excel process required. This makes lightweight validation, such as checking formula syntax, flagging external references, or scanning for risky functions, fast and scriptable. Actually recalculating results to verify output values, however, still requires a real spreadsheet engine.

Basic cell data, text, and simple formulas convert reliably between ODS and XLSX since both are open, well-documented XML formats. The risk concentrates in higher-level features: pivot tables, conditional formatting rules, chart definitions, and cell styles can shift or drop during conversion, and any embedded StarBasic macros won't translate to VBA at all — they're simply lost. A DAM's ingestion pipeline should flag converted files containing these elements for manual spot-checking rather than trusting automated conversion silently.

It depends on the application, not just the format. Modern LibreOffice Calc (7.3+) matches Excel's current grid — 1,048,576 rows by 16,384 columns — but Apache OpenOffice Calc still caps at 1,024 columns, because the ODF specification doesn't fix a grid size the way OOXML fixes Excel's at 16,384 columns for every compliant application. A DAM validating .ods files should check which application produced them rather than assume XLSX-equivalent capacity.

Yes. ODS supports embedded Basic (StarBasic/LibreOffice Basic) macros stored in a Basic or Scripts folder inside the ZIP archive, declared in META-INF/manifest.xml, much like XLSM embeds a VBA project. One practical difference for a DAM: ODS macro code is stored as plain-text XML rather than a compiled binary OLE stream, so it's easier to grep for macro presence during ingestion scanning. That doesn't reduce the risk, though — the same auto-run and execution precautions used for XLSM apply equally here.

In practice it usually wouldn't need to. Most DAM preview pipelines rely on a headless LibreOffice instance (soffice --headless --convert-to) to rasterize spreadsheets into thumbnails or PDFs, and ODS is LibreOffice's native format — often rendering more faithfully than XLSX, which goes through an import filter. The main reason to treat them differently is filter fidelity: XLSX files with heavy conditional formatting or pivot tables can render slightly off, so QA sampling matters more for XLSX previews than ODS ones.

Yes. ODS is an openly published, ISO/IEC 26300-standardized XML format with multiple independent implementations (LibreOffice, OpenOffice, Collabora), so a file isn't dependent on one vendor's continued support to remain readable — the specification itself can be implemented from scratch decades from now. The Library of Congress lists ODS in its Sustainability of Digital Formats registry for exactly this reason. Proprietary binary formats lack that guarantee, since interpreting them correctly outside their originating application isn't publicly documented.