# Spreadsheet Editor Bug: Cell formatting not applied to newly entered values

**URL:** https://community.onlyoffice.com/t/spreadsheet-editor-bug-cell-formatting-not-applied-to-newly-entered-values/21443
**Category:** Desktop editors
**Tags:** bug
**Created:** [12 November 2026 14:10 UTC](https://community.onlyoffice.com/t/spreadsheet-editor-bug-cell-formatting-not-applied-to-newly-entered-values/21443 "2026-11-12T14:10:15Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![ricardo](https://community.onlyoffice.com/letter_avatar_proxy/v4/letter/r/a6a055/32.png) [@ricardo](https://community.onlyoffice.com/u/ricardo)
#### Post date: [12 November 2026 14:10 UTC](https://community.onlyoffice.com/t/spreadsheet-editor-bug-cell-formatting-not-applied-to-newly-entered-values/21443/1 "2026-11-12T14:10:15Z")

</div>

Hi everyone,

Since the last update, I’ve been been experiencing a very annoying bug in the spreadsheet editor.

When I open either a new or an existing spreadsheet, I can select the entire sheet and apply a number format such as **Accounting**. However, when I start entering values into the cells, the numbers are displayed without any formatting, as if the format had not been applied at all.

Has anyone else experienced this issue? If so, were you able to find a solution or workaround?

Thank you.

---

<div class="post-metadata">

### Author: ![New\_Forum\_Helper\_bot](https://community.onlyoffice.com/letter_avatar_proxy/v4/letter/n/13edae/32.png) [@New\_Forum\_Helper\_bot](https://community.onlyoffice.com/u/New_Forum_Helper_bot)
#### Post date: [12 November 2026 14:11 UTC](https://community.onlyoffice.com/t/spreadsheet-editor-bug-cell-formatting-not-applied-to-newly-entered-values/21443/2 "2026-11-12T14:11:31Z")

</div>

🤖 **ONLYOFFICE Community AI Assistant**

This is an AI-generated response, not a reply from a human moderator. The suggested resources may help, but are not a confirmed fix.

This appears to match a confirmed regression in ONLYOFFICE Docs 10.0.0.1: formatting applied to an entire sheet or column may be lost when data is entered into empty cells. The issue is tracked as bug 84634, but the public report does not yet identify a released fix:

> <https://github.com/ONLYOFFICE/DocumentServer/issues/3837>
>
> \### This issue is unique.
> 
> \- \[x\] I have used the \[search tool\](https://github.co…m/ONLYOFFICE/DocumentServer/issues?q=) and did not find an issue describing my bug.
> 
> \### Operating System of DocumentServer
> 
> Docker
> 
> \### Version information
> 
> 10.0.0.1
> 
> \### Expected Behavior
> 
> When a cell has an explicitly configured font family and alignment, these formatting properties should remain unchanged when the cell value is edited.
> For example:
> Before editing
> Font: Noto Sans KR
> Horizontal alignment: Center
> After editing
> Font: Noto Sans KR
> Horizontal alignment: Center
> Both properties should remain unchanged unless the user explicitly modifies the formatting.
> 
> \### Actual Behavior
> 
> Individual formatting properties are sometimes reset independently.
> In one workbook, horizontal alignment is lost while the font is preserved.
> In another workbook, the font is lost while horizontal alignment is preserved.
> The behavior is not consistently reproducible with every edit.
> 
> \### Reproduction Steps
> 
> \_No response\_
> 
> \### Additional information
> 
> Environment
> ONLYOFFICE Docs Community Edition: 10.0.0.1
> Deployment: Docker on Linux
> Integration: FileBrowser Quantum
> Document format: XLSX
> Description
> After upgrading to ONLYOFFICE Docs 10.0.0.1, I noticed an intermittent issue where existing cell formatting is unexpectedly changed when entering or modifying spreadsheet data.
> I generally apply the following formatting to all cells in my workbooks:
> Font family: Noto Sans KR
> Horizontal alignment: Center
> However, some formatting properties are unexpectedly reset during editing.
> The affected property varies depending on the workbook.
> Case 1: Horizontal alignment is reset
> Workbook: Purchase management spreadsheet
> When entering O to mark a purchase as completed, the cell sometimes loses its horizontal center alignment.
> Observed behavior:
> Font family remains Noto Sans KR.
> Horizontal alignment changes from Center to the default alignment.
> The issue may occur when entering data into a previously empty cell or modifying an existing value.
> This behavior is unexpected because the cells have already been formatted with horizontal center alignment.
> Case 2: Font family is reset
> Workbook: Player information spreadsheet
> When entering or modifying player information, the font family sometimes changes unexpectedly.
> Observed behavior:
> Horizontal center alignment is preserved.
> The font family changes from Noto Sans KR to the document's default font.
> The issue is intermittent.
> Version Comparison
> ONLYOFFICE Docs 10.0.0.1: Issue observed.
> Earlier 9.x versions: I did not notice this behavior during normal usage.
> A controlled version-to-version regression test has not yet been completed.
> Steps to Reproduce
> Open an XLSX spreadsheet.
> Format the worksheet cells using Noto Sans KR and horizontal center alignment.
> Enter data into an empty cell or modify an existing cell value.
> Observe whether the font family or horizontal alignment changes unexpectedly.
> Repeat the operation with different cells or workbooks.
> The problem occurs intermittently, and the exact conditions triggering it have not yet been isolated.
> Additional Notes
> The issue appears to affect individual formatting properties rather than consistently replacing the entire cell style.
> I found a potentially related community report describing horizontal alignment being unexpectedly changed after upgrading to ONLYOFFICE 10.0:
> https://community.onlyoffice.com/t/onlyoffice-10-0-0-new-version-does-not-respect-format/21045
> My case also includes unexpected font-family changes in a different XLSX workbook.
> I would appreciate it if the development team could investigate whether these issues are related.
> I can perform additional testing or provide a sanitized reproduction file if needed.
> Thank you for your assistance.

A closely matching Accounting-format report was closed as a duplicate:

> <https://github.com/ONLYOFFICE/DocumentServer/issues/3872>
>
> \### This issue is unique.
> 
> \- \[x\] I have used the \[search tool\](https://github.co…m/ONLYOFFICE/DocumentServer/issues?q=) and did not find an issue describing my bug.
> 
> \### Operating System of DocumentServer
> 
> Linux (RPM package)
> 
> \### Version information
> 
> 10.0.0.169 (x64 rpm)
> 
> \### Expected Behavior
> 
> When pre-formatted cells are filled, the editor should respect the determined format. For example if it is formatted as date, it should stay as date.
> 
> \### Actual Behavior
> 
> It resets the formatting of the cell and it also removed some of the borders.
> 
> \### Reproduction Steps
> 
> 1. Open a new spreadsheet.
> 2. (Optionally) Select a few columns as a whole, apply "all borders".
> 3. Select a column and select "accounting style"
> 4. Fill a cell in this column with some numbers.
> 5. You will see that the cell will default back to "general" style.
> 6. If you applied borders on step two; you will see that some of the borders around the cell are also deleted.
> 
> Also something additionally wrong with the date format:
> 
> 1. Format a column in the same sheet as "date".
> 2. Fill in a cell with a date like 31.10.2026
> 3. Copy this cell and paste it below onto another cell.
> 4. It will paste 46326. Not only turning the cell style into "general" but will also alter the data.
> 5. If you re-paste on the same cell without changing anything, now it will paste correctly.
> 6. Now if you paste one cell below again, it will again paste 46326
> 
> Each time only the second pasting works on a cell and that cell never breaks the formatting again, no matter how many times you paste on it.
> 
> \### Additional information
> 
> As far as I am aware, the bug surfaces only if:
> 1- No borders are used in the sheet.
> 2- Or full columns or rows are selected and applied "all borders".
> 
> So for example when you select a fews cells and apply borders, the bug will not surface.
> 
> The date format bug will prevail regardless. See the screenshot below. If you draw borders only over a few cells, but select the whole column as date style, pasting inside the bordered area works; but pasting on this date column outside the bordered area still breaks.
> 
> \<img width="454" height="340" alt="Image" src="https://github.com/user-attachments/assets/50aff241-ce4a-4569-a924-9e4ef0289adc" /\>
> 
> A note about the operating system: I was using Fedora Cosmic when I first noticed this bug. Later I re-formatted the machine all over and installed Fedora KDE, and installed Onlyoffice again, and the bug was still there. So it shouldn't be something specific to my OS I guess.

As a workaround, apply Accounting format only to the specific cells or range you intend to use, rather than the whole sheet or whole columns. If values are already entered, select that range and reapply Accounting. The official instructions confirm that whole-sheet formatting should normally work:

> **[Changing number format | ONLYOFFICE Help Center](https://helpcenter.onlyoffice.com/docs/userguides/spreadsheet-editor/editing-cell-properties/change-number-format)**
>
> Change the number format of cells to display numbers, currency, dates, times, percentages and fractions in the most convenient way, and customize it in the Spreadsheet Editor.

* * *

👤 **Need assistance from a human moderator?**

Click the 🚩 **Flag** option on this post and select **Request Moderator Assistance** to request a review by the moderation team.

---

<div class="post-metadata">

### Author: ![Jared\_Sh](https://community.onlyoffice.com/letter_avatar_proxy/v4/letter/j/e5b9ba/32.png) [@Jared\_Sh](https://community.onlyoffice.com/u/Jared_Sh)
#### Post date: [13 November 2026 09:57 UTC](https://community.onlyoffice.com/t/spreadsheet-editor-bug-cell-formatting-not-applied-to-newly-entered-values/21443/4 "2026-11-13T09:57:37Z")

</div>

Hello @ricardo ,

I’ve added this request to the existing bug 84680. We’ll post here as soon as there’s any news on it.
