Small and medium business | Business Central, N...

The record in table Excel Buffer already exists.

(3) Share

Report

Posted on by MB-22100407-0

122

🚨 Need Help – Business Central Excel Export Error in Consolidation Company

Hi everyone,

We are currently experiencing an issue in Microsoft Dynamics 365 Business Central when exporting Financial Reports/Account Schedules to Excel.

The issue occurs only in our Consolidation Company and is happening across all reports that we have tested.

What is interesting is that the same reports work correctly in our other companies, and we are able to successfully extract them to Excel. This makes us think the issue may be specific to the Consolidation Company data, setup, or configuration, rather than the reports themselves.

Error Message

The record in table Excel Buffer already exists. Identification fields and values: Row No.='3',Column No.='3'

Environment

Business Central Version: 28.4.53241.53939
Issue: Exporting Account Schedule / Financial Reports to Excel
Affected: Consolidation Company only
Other Companies: Same reports are working and can be exported successfully

AL Call Stack

"Export Acc. Sched. to Excel"(Report 29).EnterCell line 18
- Base Application by Microsoft version 28.4.53241.53939

"Export Acc. Sched. to Excel"(Report 29).InsertBlankRowAndFillCells line 8
- Base Application by Microsoft version 28.4.53241.53939

"Export Acc. Sched. to Excel"(Report 29).PopulateExcelBuffer line 67
- Base Application by Microsoft version 28.4.53241.53939

"Export Acc. Sched. to Excel"(Report 29)."Integer - OnAfterGetRecord"(Trigger) line 27
- Base Application by Microsoft version 28.4.53241.53939

"Acc. Schedule Overview"(Page 490)."Create New Document - OnAction"(Trigger) line 7
- Base Application by Microsoft version 28.4.53241.53939

Additional Details

The error consistently points to:

Excel Buffer → Row No. = 3, Column No. = 3

Since the same Account Schedule reports can be exported successfully from other companies, we are trying to determine what could be different specifically in the Consolidation Company.

Could anyone advise what we should investigate?

In particular:

Could this be caused by Consolidation Company setup or data?
Could there be something in the Account Schedule rows/columns or formulas that is causing the duplicate Excel Buffer entry?
Are there any specific Consolidation settings or records we should check?
Could existing/duplicate data in the Consolidation Company cause the Excel Buffer to attempt inserting the same Row/Column combination?
Is this a known issue in Business Central 28.4?
Is there a recommended workaround, hotfix, or update for this issue?

Any advice from someone who has encountered a similar Excel Buffer duplicate record error specifically in a Consolidation Company would be greatly appreciated.

Thank you in advance for your help! 🙏

#BusinessCentral #Dynamics365 #D365BC #MicrosoftDynamics #ExcelBuffer #AccountSchedule #Consolidation #FinancialReporting #ALDevelopment

Categories:

Dynamics 365 Business Central

All responses (7)

Answers (0)

Sort by

Suggested answer

OussamaSabbouh 20,124 Super User 2026 Season 2 on at

Like (1)

Report
Copy link

Link copied!

Hello,
This is not caused by old records remaining in Excel Buffer—Microsoft documents Excel Buffer as a temporary table, where each record represents one Excel cell and the key is Row No. + Column No.; therefore this error means Report 29 is trying to create cell C3 twice during the same export. Also, Row No.=3 / Column No.=3 refers to the generated Excel coordinates, not necessarily row/column 3 of your Financial Report definition. Because all Financial Reports fail only in the Consolidation Company, I would first test a very simple Financial Report there (one G/L row + one column); if that also fails, focus on company-specific Financial Reporting/G/L setup rather than individual formulas. One important point: Microsoft actually lists hotfix 637755 – “Fix duplicate rows in Financial Report Excel export after adding G/L Budget Dimension” in BC 28.4, which is directly in this area. Your application build 28.4.53241 is the build containing that fix, so I would specifically compare the G/L Budget Dimensions / financial reporting dimension setup in the consolidation company with a working company and confirm that all System/Base Application apps really show the expected 28.4 versions. If the simple report still produces the duplicate-cell error on 28.4 with Microsoft-only extensions, I would raise this to Microsoft Support with the call stack and mention hotfix 637755, because the consolidation company itself should not require a different Excel Buffer mechanism and this could be a remaining/reproducible variant of that defect.
Regards,
Oussama Sabbouh
Suggested answer

CU03020606-0 88 on at

Like (0)

Report
Copy link

Link copied!

Hi,
The error is interesting because it is specifically pointing to Row 3 / Column 3 in the Excel Buffer. This basically means Report 29 is trying to write to the same Excel cell twice.
Since the same reports are working fine in your other companies, I would first compare the Account Schedule row/column setup and the filters between a working company and the consolidation company.
I would also try creating a very simple Account Schedule in the consolidation company and export that to Excel. If the simple one works, then you can narrow it down to something in the existing row/column setup. If even a basic Account Schedule gives the same error, then I would start looking at the BC 28.4 build itself and potentially raise it with Microsoft.
I would check the Business Unit/Consolidation filters as well, but I wouldn't assume that the consolidated G/L data is corrupt just from this error.
I also wouldn't recommend trying to fix this by simply ignoring the duplicate Excel Buffer record. That could hide the actual problem and potentially give you an incorrect Excel output.
The main thing I'd try to find out is why Report 29 is generating cell C3 twice.

Thanks,
Sanket
Suggested answer

Grigorios Mavrogeorgis 3,638 Super User 2026 Season 2 on at

Like (0)

Report
Copy link

Link copied!

Hi, first check the Excel Buffer table itself in that company. It's a normal company-specific table, and if some export died halfway once, physical records stay behind and every next export then hits a duplicate on the same Row/Column. That would explain why only this one company breaks while the others are fine.
You can open it straight from the URL with ?company=YourConsolidationCompany&table=370 and see if there is anything in it. If yes, delete the lot and try the export again.
If the table is empty, then it's the report definition, so look at the column layout for two columns carrying the same number, and at the row definition for repeated row numbers.
Glad to help - follow up if anything is unclear.
► If this solved it, marking it verified helps others too.
Regards,
Grigorios Mavrogeorgis
Business Central Consultant & AL Developer
Work: Gmsoft Limited
Blog: insidebusinesscentral
LinkedIn: linkedin.com/in/gregorymavrogeorgis
MB-22100407-0 122 on at

Like (0)

Report
Copy link

Link copied!

@Grigorios Mavrogeorgis Table 370 (Excel Buffer) has no data in it, and I've checked the report definition, column definition, and row definition - everything looks fine there as well. I also created a simple, brand-new report to test, but the same issue still occurs.
This issue is affecting all Financial Reports.
Suggested answer

Grigorios Mavrogeorgis 3,638 Super User 2026 Season 2 on at

Like (0)

Report
Copy link

Link copied!

Hi forget the table, that was my mistake. The buffer in that report is temporary, so empty 370 tells us nothing.
Row 3 column 3 is still up in the header part. The schedule lines aren't even reached yet, that's why every report dies the same way, even your new one.
When you made the test report, did you make a new column definition too, or did it grab the same one that's already there? These definitions are company data, and you can have two lines with the same Column No. or the same Row No. without BC complaining, because the key is Line No. On the page it looks completely normal. I'd open the tables directly and sort on those two fields.
If they come back clean then you need to attach the snapshot debugger in that company and you will see which EnterCell fires twice.
MB-22100407-0 122 on at

Like (0)

Report
Copy link

Link copied!

Hi @Grigorios Mavrogeorgis
Wanted to share a full update on the testing we've done so far for the "Excel Buffer already exists" error (Row No.='3', Column No.='3') when exporting from Acc. Schedule Overview (Page 490) / Export Acc. Sched. to Excel (Report 29).
Here's everything we've tested and ruled out:
1. Telemetry review: pulled the Application Insights record for this error. It confirms the failure originates entirely within Base Application code - no third-party or custom extension appears on the AL call stack at the point of failure.
2. Scope of impact: confirmed this affects ALL Financial Reports, not just one specific report.
3. Fresh report test: deleted all existing row and column definitions and created a brand new Financial Report from scratch - same error still occurred.
4. Minimal/clean report test: created a new test report with a completely new and clean Row Definition and Column Definition, kept to only 2 lines each, with no formulas, budget references, or dimension filters - same error still occurred.
5. Different users: tested with multiple different users - same error every time, ruling out a user-specific cause.
6. Different browsers: tested in different browsers and in incognito/private mode - same error every time, ruling out browser cache/cookie/session issues.
7. Table 370 (Excel Buffer) check: used a read-only diagnostic page to check the table directly - it is empty at rest before export, ruling out leftover/orphaned data as the cause.
8. Column Layout data review: exported and reviewed the full Column Layout dataset - found no duplicate Row No./Column No. combinations or structural issues in the layout definitions.
9. Budget/dimension investigation: identified that the "P&L BUDGET" G/L Budget had blank Budget Dimension 1-4 Codes, and that a specific Column Layout (Z-BVA-QTR) referenced this budget - a pattern matching Microsoft hotfix 637755 ("Fix duplicate rows in Financial Report Excel export after adding G/L Budget Dimension"). Deleted this Column Layout to test - same error still occurred on other reports, so this does not appear to be the root cause.
10. Extension testing: uninstalled all extensions in the environment one at a time to isolate a possible cause - same error persisted after each uninstall, and also after all extensions were removed entirely.
11. Environment-wide test: all extensions and system customizations were uninstalled in the PRODBACKUP-12172024 environment as a clean test - the error still occurred.

Given that we've now ruled out report configuration, row/column definitions, budget/dimension setup, users, sessions, browsers, extensions, and customizations, we believe this points to something within Base Application itself, specific to this environment/Consolidation Company setup.
Let me know if there's anything else you'd like us to test, or if this gives you enough to investigate further on your end.
Thanks,
Bret
Suggested answer

Akash Raj 127 on at

Like (1)

Report
Copy link

Link copied!
Hi @MB-22100407-0 ,
Confirming this checking LCY Code in the consolidation company is the right fix, and I can add the exact reason why so it's not just a guess.
Root cause: In Report 29 "Export Acc. Sched. to Excel", the PopulateExcelBuffer procedure builds the currency-info row like this:
InsertBlankRowAndFillCells(RowNo, 3, true, false); // inserts a new row, fills columns 1–3 blank if UseAmtsInAddCurr then EnterFilterInCell(RowNo, GLSetup."Additional Reporting Currency", ...) else EnterFilterInCell(RowNo, GLSetup."LCY Code", ...); InsertBlankRowAndFillCells(RowNo, 3, false, true); // fills column 3 again on the SAME row
EnterFilterInCell only writes anything if the value passed in is not blank. When General Ledger Setup."LCY Code" is blank (which is the standard/default setup in most BC companies blank is BC's own convention for "this is the local currency"), that middle call does nothing and the row number never advances. The next line then tries to write column 3 of that same row a second time but column 3 was already written by the first InsertBlankRowAndFillCells call two lines above. That's a guaranteed duplicate insert into Excel Buffer, which is exactly the "Row No.='X', Column No.='3'" error.
So the fix:
Go to General Ledger Setup (in the consolidation company) → check the LCY Code field.
If it's blank, set it to your functional/base currency's ISO code (e.g., USD, EUR) as long as that currency code already exists in your Currencies table.
Retry the Excel export from Acc. Schedule Overview / Account Schedules.
This is a genuine base-application defect (it happens purely in the header section of the report, completely independent of what's in the account schedule or column layout no need to touch either), reproducible on any schedule as long as LCY Code is blank and you're not using Additional Reporting Currency. Worth logging with Microsoft Support too, referencing Report 29 → PopulateExcelBuffer → the two InsertBlankRowAndFillCells calls around the LCY Code line — they'll have everything they need from your session/telemetry IDs to confirm and hopefully get it patched upstream.

Thanks.