Gnumeric Troubleshooting and Error Reference
Decide which kind of failure you have
Preserve the original file and work on a separately named copy. Record the Gnumeric version, Linux distribution, file format, exact formula and visible message. The general guidance covers Gnumeric desktop 1.12-series documentation checked on 2026-10-21. The separately scoped DURATION case below adds 2026-10-22 command-line observations; it does not validate the graphical workflows. Distribution builds and translations may differ. This reference makes no current Windows-build claim.
Start with the distinction that saves the most time: a formula-entry warning, a calculated error value, a clipped display and an incorrect numeric result require different investigations. Recalculation does not repair the wrong reference, and widening a column does not repair invalid arithmetic.
Read the visible symptom
The official data-types and error-elements reference documents these distinctions:
| Symptom | First diagnostic direction |
|---|---|
| A formula-entry warning | Inspect the expression before accepting it as text. A stored text expression is not a repaired calculation. |
| A row of hash marks | Widen the column or inspect the selected cell’s data-entry area. The value may simply not fit. |
#DIV/0! |
Inspect the divisor and the inputs producing it. |
#NAME? |
Check a function or defined name that cannot be resolved. |
#NUM! |
Check whether a numeric argument is valid for the operation. |
#REF! |
Inspect the referenced address and any deleted or moved source. |
#VALUE! |
Check the argument types. |
#UNKNOWN! |
Investigate an imported error that Gnumeric did not recognize. Preserve the source file for comparison. |
#N/A |
Establish whether an unavailable result is intentional or signals missing input. |
#NULL! |
Inspect an intersection of ranges that may not overlap. |
This is a routing table, not a promise that one symptom has only one cause. Begin at the earliest failing input, not at the last total that repeats its error. Avoid wrapping every formula in an error handler before identifying the cause: doing so can turn broken data into apparently clean output.
If the number looks valid but is wrong
Use the existing formula-result diagnostic exercise. It separates calculation freshness, wrong dependencies, numeric-looking text and display precision, and provides independently calculated expected results. Follow its change-and-restore tests rather than retyping a total to match an expectation.
For copied formulas, compare the first, middle and last rows with relative, absolute and mixed references. A single fixed row reference can produce a plausible value throughout an otherwise correct column. For labels used in formulas, inspect the intended named range rather than changing every occurrence of the name blindly.
A reproduced DURATION discrepancy in 1.12.62
A number can also disagree with an independent model after fresh calculation. In the specific test below, changing settlement from a coupon date to halfway through the annual coupon period did not change DURATION’s result, although the timed cash-flow reference changed by 0.5 year.
Test scope: Gnumeric 1.12.62, GOFFICE 0.10.61, Debian 13 Linux x86-64, headless ssconvert calculation, C.UTF-8 locale and UTC, checked October 22, 2026. The discrepancy was independently reproduced after removing formula caches. This is an observed software discrepancy, not a vendor-confirmed or universal bug claim. No GUI or receiving application was tested.
The official DURATION help describes Macaulay security duration. These synthetic inputs use annual payments and US 30/360, not a growth-period calculation:
| Cell | Entry | Meaning |
|---|---|---|
| B2 | =DATE(2024,1,1) |
Coupon-date settlement |
| B3 | =DATE(2026,1,1) |
Maturity |
| B4 | 0.05 |
Annual coupon rate, 5% |
| B5 | 0.04 |
Annual yield, 4% |
| B6 | 1 |
Annual payment frequency |
| B7 | 0 |
US 30/360 basis |
With those inputs, the native CLI observations and independent references are:
| Expression | Observed Gnumeric result, years | Independent reference, years |
|---|---|---|
=DURATION(B2,B3,B4,B5,B6,B7) |
1.952813067151 | 1.952813067151 |
=DURATION(DATE(2024,7,1),B3,B4,B5,1,0) |
1.952813067151 | 1.452813067151 |
The table rounds to twelve decimal places. For 100 nominal units, the remaining payments are 5 on January 1, 2025 and 105 on January 1, 2026. At the January 2024 settlement they occur in one and two years. Their discounted time-weighted mean is (1*5/1.04 + 2*105/1.04^2)/(5/1.04 + 105/1.04^2), exactly 1076/551 years.
At the July 2024 settlement, the same payments are 0.5 and 1.5 years away under this basis. Using those times in both discounting and weighting gives (0.5*5/1.04^0.5 + 1.5*105/1.04^1.5)/(5/1.04^0.5 + 105/1.04^1.5), exactly 1601/1102 years. A common discount factor cancels, so this reference is exactly one-half year below the first. The native result stayed at the first value. Agreement on the coupon-date case therefore does not validate the mid-period case.
The released 1.12.62 source archive helps explain this observation. In plugins/fn-financial/sc-fin.c, the Duration helper weights and discounts whole coupon ordinals; it does not use its settlement, maturity or basis parameters. The wrapper in plugins/fn-financial/functions.c supplies the remaining coupon count. This source reading explains the tested case, not every possible date schedule.
Keep any affected operational result unvalidated until its actual cash-flow timing has been checked independently. Recalculation, extra displayed decimals and IFERROR do not correct this discrepancy. Do not subtract 0.5 from every DURATION result: that difference belongs to this exact example, not a general repair. Nor should you change a real settlement date to a coupon date merely to obtain agreement. Preserve the original, record the exact build and inputs, and retest the real schedule in any proposed replacement calculation or application before relying on it.
G_DURATION is a different growth-period function, not a substitute. This bounded software check is not a general bond calculator or financial advice, and establishes no result for another Gnumeric version, another platform or another application.
If the problem starts with a file or an edit
- CSV fields, decimal values or dates are wrong: return to delimiter and decimal import settings. Test a small sample from the unchanged source. Do not erase punctuation across all columns; identifiers and amounts need different treatment.
- The workbook changed after exchanging formats: use file-format compatibility checks. Keep both the original and converted file and compare formulas, not just displayed values.
#UNKNOWN!is a reason to investigate the import, not to replace unknown results with zero. - An entry is rejected: distinguish validation rules from protection settings. Ask the owner whether a rule is intentional before relaxing it.
- An export lacks expected workbook features: review clean CSV export. Treat the export as a separate data delivery, not your editable master workbook.
- Only a printout is clipped: inspect print/PDF output before changing underlying values.
When a reproducible problem remains
In the documented Help menu, About identifies the application version and Report a Problem opens the project’s reporting destination. Preparing a report does not require you to publish the workbook immediately. First reduce a copy to the smallest non-confidential example that still fails.
Include the version, distribution, input file format, exact steps, expected outcome and actual outcome. Say whether a new workbook behaves the same way and whether the failure occurs only after import or reopen. Do not claim that a different application’s output proves Gnumeric is wrong without checking formula semantics and input types.
Before accepting a repair, change an input that should affect the result, check the response, restore the intended input, then save and reopen the repaired copy. Retain the original until those checks pass. The DURATION case above is the only native calculation evidence on this page; the general graphical troubleshooting steps remain documentation-supported, not GUI-tested.
Calculation error reference
For worked examples of specific formula errors, browse the calculation error reference. Use the relevant guide on a disposable example or a copy of your workbook.