I am running Manager Desktop on a Windows 11 Pro version 25H2 (OS build 26200.7462) 64 bit PC. In Desktop version 25.12.6.3147, in the Reports tab, when I view a Profit and Loss Statement (Actual vs Budget) report in the Edit mode, the Revenue amounts are positive numbers & the Expense amounts are negative numbers, the way it always has been in the past. However, in this 3147 version, when I press Copy to clipboard & paste the report into Excel 365, all the Revenue & Expense numbers display as positive. Also, the header information used to come across with the Copy to clipboard function, but it no longer does.
The same problem occurs with the Profit and Loss Statement report.
Please advise what has changed & if the Copy to Clipboard function can be restored to how it previously functioned. Thank you.
Yes, I agree that these reports all need to display positive numbers for both Revenue & Expense amounts in the on-screen Manager View modes, as well as all custom Excel spreadsheet reports that the data is pasted into**.** However, in the Edit modes, for these reports in Manager, the Expense numbers are all negative, in this new version, as well as all previous versions. In previous versions, the Copy to clipboard function copied the actual numbers from the Edit mode (where the Expense numbers are all negative), to the clipboard. The current version of Manager seems to copy the numbers from the View mode instead of the Edit mode. This causes havoc when the data is pasted into Excel spreadsheets that are preformatted to expect Expense numbers that are negative. Is there any way the function of Copy to clipboard can be restored to how it previously worked? Thank you.
When that changed the report headings were also lost in the clipboard copy, and instead of the actual values it is sending the result after formatting. This makes a zero or null appear as a dash. Pretty much all of the deviations can be handled on the Excel side except for the lack of headings, which means all references to report name, reporting period, and accounting basis are lost.
For those using the import to feed Excel to produce dynamic selective graphs or reports, the heading loss makes the reports truly useless.
When I report is copied to clipboard, the pasted format should be understandable immediately.
And given that heading, subtotals, and totals are present and not formatted, it is difficult to understand the reports and difficult to format these reports as well.
I think either:
the copied data maintains the on-screen formatting
the copied data shows the signs not shown on-screen
the on-screen report format is changed so that when it gets copied, itâs much easier to understand, or
maybe some other smarter solution
This has been an issue for quite a while now that hasnât made it into bugs, so I guess this should be an idea for new development.
For some situations, unless Manager handles the IEEE-754 problem potential behind the scenes, using the formatted values as actual values can cause some errors/discrepancies. Essentially, any value calculated by elements consisting of fractions and signs can produce errors if not forced to a precision by either rounding or having the format enforce the precision on the number stored (as is possible in Excel). At the most basic level, you could wind up with a value that shows as either 1 or 0, but which when tested against 1 or 0 will fail. The effect can be easily demonstrated in Excel as long as formats are not applied or when Excel is set to not store values as formatted, by entering the following formula into a cell â=41.1-41.2+1.1â. The result will show as 1, and if you work it out in your head, the result is also 1. If you test that cell against the value of 1 however, it will come back as false. Aside from all of that, why is it that when something that used to work, no longer works, it isnât called a bug?
It comes down to what is of interest, the data or the report format. The two are not in any way equal, and the ideal situation would be to allow selection of which you were interested in getting. For importing into Excel, the data is far more valuable than the report format of the data, and allows for the detection of errors and problems that may be hidden by the formatted results.
Using VBA to do the import allows for changing the sign, and also checking for the text â-â instead of the expected 0. However, there is no way to detect a discrepancy (such as may occur due to floating point errors) between the data and the formatted data.
As for the P/L and BS reports, when viewing the report you can select all of the information and copy it to the clipboard manually, which will get you the headings missing in the app copy since September 2025. Itâs still formatted data instead of actual data, but it at least has the qualifying information contained in the headings.
The ideal situation would be that the copy to clipboard would request the selection of formatted report data, or underlying source data. If you wanted the values to appear as they do on the report, go with the formatted version, otherwise, if you are after the real numbers from the system for use in Excel, go for the actual data. The reference that has been made to âLess expensesâ is something that has no significance from a data perspective, as it is only a text descriptor line on the report. The values are negative, and should you want the values, thatâs what should be obtained.
The values may be assessed negatively, but they have a positive value.
I remain in favour of the administration programme following accounting rules whereby positive amounts are used and the debit or credit side determines the value (balance) of the general ledger account.
Costs are deducted from revenues, but recorded as positive amounts on the debit side.
It is up to the creator of the report to display amounts as negative if, in their opinion, this improves readability. And we have excellent spreadsheets for this, such as Libre Calc.
If the report listed debit and credit columns under each divisional/account heading, I would agree, but it does not. The items (accounts) are listed with a single value for each divisional group. The report itself makes sense with positive expense values due to the descriptor line âLess expensesâ, but for transferring data to another application (Libre Calc or Excel) if you donât want to have to make adjustments based on processing each row of the data, toggling a sign multiplier on seeing certain text, the values in a copy should reflect their logical sign. Also, it isnât that expenses are being shown as positive, itâs that they are being shown after negation. Altering the value may make for a nicer report, but when copying the data it should remain unaltered. A similar situation exists with the Balance Sheet report, but the need to alter signs is more complex there.
Itâs a bit of a pain losing the headings because you have to manually label everything in Excel afterward. One thing that sometimes helps is using a browser extension like âTableCaptureâ to grab the HTML table directly - it usually keeps more of the structure intact than the built-in clipboard button.
You can select the report (at least the PL/BS) and do a manual copy, then open excel and paste. If you are working with a VBA script which handles the import and other processing, it works fine, allowing the information in the header to be used like before the âimprovementâ. If thatâs so, then your scripts will also need to be altered to detect the text indicators for needing negation, and also interpret the â-â as a null or zero since the âimprovementâ also sends the formatted result, not the actual data.
Pretty much anything can be worked around, but loss of the heading data means that the data being imported involves assumptions, and has no hope of validation for date range, report type, or basis if the copy button is used. Using the formatted results instead of the actual underlying values also hides any floating point issues that may exist, as the formatted representation may not actually reflect the actual value, regardless of sign.