Spreadsheet bug: Formula outputs not visible

Report a bug
OS version: Mac OS Tahoe 26.6.2 (25G83)
App version: 9.4.0
Downloaded from: ONLYOFFICE website
Additional information: Entering a formula displays no output, unless the spreadsheet is saved, closed and reopened.
Any relevant details about the situation: This bug was reported in older versions and has clearly crept back.

Hi @steelem ,

Any specific formula, or all formulas?

For instance, I have been bumping into a similar issue with SUMIF(), but I haven’t raised a ticket yet, as I am still in the process of qualifying the conditions.

Hi, this is occurring with all functions I have tried. See screen recording video at the attached link

Link to video demonstrating bug

Furthermore, saving the file doesn’t resolve the problem. Once the file is saved and reopened, the outputs of the function are visible, but reverts to being invisible as soon as the function is changed. The bug repeats when a new function is entered. The spreadsheet itself was created by Claude and functions correctly in all other apps including Libre Office and Excel.

I can’t see your video. Maybe iDrive only plays back on Apple computers :thinking: Doesn’t like Firefox on Windows :blush: Either that, or content delivery speed is through the floor.

It may be prudent to upload a copy of a speadsheet created on your computer, for issue testing. Getting nil result from all formula sounds too much like a specific installation issue. This forum would be hammered if OnlyOffice demonstrated that issue for everyone.

This bug is 100% reproducible. I suspect this bug is only occurring on spreadsheets created by Anthropic’s Claude, hence the forum isn’t being hammered. Nevertheless, the bug does not occur when the same Anthropic-created spreadsheets are opened in Libre Office and Excel.

Having recently registered, this site considers me a new user and blocks me from uploading files. This is why I posted a link. I’ve saved the video as an MP4. Try this link:

https://drive.google.com/file/d/1H3E9mNRDRUpIbF5P-B1GihilwKgmCJad/view?usp=sharing

https://drive.google.com/file/d/16FzhiiCIy8cox8Ogs10oQX6wXEuBTciu/view?usp=sharing

I thought one of those file links may have been the spreadsheet itself, but they are both videos. And yes, while it does demonstrate the issue, that is not enough, at least for me, to work with.

However, something you did mention is quite critical; you said the spreadsheet was created by an AI engine. That sounds like the most important factor. It would seem that the AI generated spreadsheet XML code is not compatible with OnlyOffice; and as Microsoft, Libre, and OO each create their own XML code versions of the spreadsheet, there must be something in that code that disrupts the XML processor in OO.

Obviously the next step would be to create a spreadsheet from “new” in OO, and see if the issue is still there, if not, then that proves that the AI code has elements that OO cannot process.

Also, as you mention that Libre and Microsoft can open the document, did you try saving the spreadsheet, and then opening in OO? Every spreadsheet application rewrites the spreadsheet code in their own format, so Libre, for instance, may adjust spreadsheet XML in a way that OO can read correctly.

As I mentioned previously, if you provide a copy of the spreadsheet that you are using, then the OO developer team may be able to take into consideration the XML spreadsheet code being created by Claude.

Hi @steelem,

Thank you for the recording and the additional details.

To investigate the issue, please attach the original spreadsheet file generated by Claude (before opening or resaving it in LibreOffice or Microsoft Excel). The recording confirms that formula text is shown in the formula bar while the calculated result is not displayed in the cell, but we need the source file to reproduce and analyze the issue.

Please also clarify:

  • Does the same behavior occur if you create a new blank XLSX file in ONLYOFFICE Desktop Editors and enter a simple formula such as =1+1?
  • Does it occur with every XLSX file generated by Claude, or only with this particular file?

I have raised your forum trust level, so you can now attach files directly to the forum.

Hi Marix, thanks for lifting the trust level, although the forum is still telling me “Sorry, new users can not upload attachments” and limits me to two links, so the files are in a shared Google Drive folder:

The files are stored as native .xlsx. Please right-click each file and choose Download to get the original; do not open with Google Sheets and save, as that converts the file and rewrites the XML. Three files:

  1. demo2.xlsx: an anonymised copy of the workbook, numbers randomised, as delivered to me. This reproduces the fault.
  2. demo2_openpyxl_only.xlsx: the same workbook before its final build step (see below), as close as I can get to the file you asked for. It has no cached values, so the editor calculates everything on open. This also reproduces the fault.
  3. oo_format_test.xlsx: a small single-sheet file built the same way, with the same fonts and number formats, and no real data. This one works correctly: type =AVERAGE(B5:B10) into row 12 and the result displays.

A note on how the files are built, since you asked for a file untouched by LibreOffice. Claude writes the workbook with the Python library openpyxl, then runs LibreOffice headless to recalculate it so that the cached values are present. So demo2.xlsx was last written by LibreOffice even though I have never opened it there myself; demo2_openpyxl_only.xlsx skips that step.

Steps to reproduce in Desktop Editors 9.4.0 on macOS Tahoe 26.6.2: open file 1 or 2, go to the Annual sheet, click any cell in row 120, enter =AVERAGE(C120:F120). The formula appears in the formula bar but the cell stays blank. Save, close and reopen, and the result is displayed. Edit the formula again and it goes blank again.

Answers to your questions:

  • New Claude-created blank XLSX in Desktop Editors, =1+1: works correctly.
  • It is specific to this workbook. File 3 comes from the same generator with the same fonts and number formats and works correctly, so it is not the generator or the number formats as such.

One correction to an earlier post: I wrote that the workbook works in LibreOffice and Excel. It should have read LibreOffice and WPS Office. I have not tested it in Excel.

What is different about this workbook is its size and structure: ten sheets, 18,045 formulas, mostly SUMIFS and COUNTIFS with text and date criteria across sheets, nested to depth 7, plus one line chart, two cell comments and a few merged ranges. No macros, defined names, data validation, conditional formatting or external links.

Happy to run any further tests you suggest.

Hi @steelem ,

After looking at your sheets, I can see that the issue is related to the use of SUMIF() as I alluded to in my first post.

I jumped to the “Payment Profile” tab, and in cell F22, I added the formula =AVERAGE(F6:F20) and the result was a blank cell displayed. Although looking at the XML file, I could see that the value 58573.802429333336 had been stored.

<c r="F22" s="43"><f>AVERAGE(F6:F20)</f><v>58573.802429333336</v></c>

On the sheet, this was display, after closing and re-opening the sheet, as 58573.80243

On the same saved spreadsheet, I typed a similar formula into cell F21, and in that case too, the resultant value did not display, at least until the spreadsheet was saved, closed, and re-opened, as before.

However; if I used the formula replication process and dragged the selection from E22 to D22, the expected formula was inserted and cell value was displayed.

Screenshot 2026-09-15 160052

I could see how OnlyOffice alters the XML code, but I could not see how this would be impacting the issue;

<c r="F21" s="40" t="n"><f aca="false">SUM(F6:F20)</f><v>878607.03644</v></c>
<c r="F21" s="41"><f>SUM(F6:F20)</f><v>878607.03644000005</v></c>

… the first line is from demo2.xlsx, and the second line is from demo2.xlsx after it had been edited and saved by OO.

That is what I have observed, if it is of any use.

Update after bisecting the workbook. To narrow this down I built 41 test workbooks (cut-down variants of the forecast with individual sheets, row blocks or constructs replaced by values, plus small synthetic files) and tested about 35 of them in Desktop Editors, along with a dozen typed-formula sequences in blank workbooks.

Summary first: the values are always calculated correctly; what fails is the repaint of the edited cell. A small reproduction file is now in the shared folder (oo_repro_41.xlsx, 323 formulas, no real data).

Recipe with oo_repro_41.xlsx, Desktop Editors 9.4.0, macOS Tahoe 26.6.2:

  1. Open the file. The Probe sheet lists nine formulas in column A, each reading a cell on the Calc sheet, which in turn sums or counts a row on the Data sheet.
  2. Type the first formula into B3, the second into B4, the third into B5 (type them; do not copy or fill).
  3. B3 and B4 display their results. B5 stays blank, and so does every formula typed after it. Which formulas are used does not matter: the third typed formula that references other cells is always the first blank one.
  4. The blank cells are computed. Filling a formula from a neighbour, or saving and reopening, makes them all appear at once. They also show the correct value in the XML, as David found.

What does not reproduce it: a new blank workbook with up to eight typed formulas referencing each other, or referencing a 150-cell row of values or of formulas on the same sheet. Formulas that reference nothing (=1+1) never count towards the limit. Formulas typed after a fresh open of the file always display, so this is state that builds up within a session as formulas referencing other cells are typed.

In my full workbook (demo2.xlsx in the same folder) the first typed formula already fails, provided it references a cell whose precedents lead into the large Monthly Forecast sheet (for example =AVERAGE(C120:F120) on Annual); a typed formula referencing plain values displays normally. So the budget seems to be consumed by the size of the dependency tree pulled in by each typed formula, and the full workbook exhausts it in one edit.

Happy to run anything else that helps.

PS, I still cannot upload any files

Hi Marix, could you confirm whether the reproduction file and recipe I posted on 16 September have reached your developers, and whether a bug has been logged? If so, the tracker reference would be useful so I can follow it.

To recap what is in the shared folder: oo_repro_41.xlsx reproduces the fault deterministically in under a minute (the third typed formula referencing another cell renders blank), demo2.xlsx shows it on the first edit, and the calculated values are present in the saved XML in both cases, so the fault is confined to the repaint after a formula is committed. I spent several hours over 41 test workbooks isolating this so that it would cost the development team as little time as possible.

If anything further is needed to reproduce it on your side, or if a different channel (GitHub issues, a support ticket) is the right place for this level of detail, please let me know and I will take it there.

Hi @steelem,

Thank you very much for the exceptionally detailed investigation. We truly appreciate the time you spent isolating the issue, preparing test workbooks, creating a minimized reproduction file, and documenting the exact conditions under which the problem occurs.

The reproduction scenario and the files you provided are very helpful. We have forwarded the case to our QA team for verification.

We will update this thread as soon as we receive their feedback.

Hi @steelem,

Thank you again for the detailed reproduction materials and investigation.

Our QA team has verified the issue in version 9.4.1. The problem no longer reproduces in version 10.0.0, which is currently under testing.

The fix will be included in the next release. We will update this thread once version 10.0.0 is officially available.

Hi @steelem,

ONLYOFFICE Desktop Editors 10.0 is now available and includes the fix for the formula result display issue you reported.

Please update to version 10.0 and let us know whether the issue is resolved on your side.

Thank you again for your thorough investigation and the reproduction files!