Working with the Price function, basis 2 and 3 (Actual/360 and Actual/365) are giving different results than the price function in Excel. Why? Is there a way for me to make them give the same results?
Edit to provide detail
I’ve tried setting the date system to 1900 to match Excel in Windows and there is still discrepancies. I’m including pictures as an example: 
@Hrbrgr - reopened, since this seems a valid question about function PRICE() in LibreOffice Calc compared to Excel. I cannot verify the differences claimed by OP, since I got not Excel and there are no technical details or examples, but it’s a legit topic (even if it will turn out that it is a bug, which we don’t know for now).
Could it be the difference in what the user has set as date zero in Excel
And what the user has set in LibreOffice Calc? Tools > Options > LibreOffice Calc > Calculate
@anon73440385, That’s OK, the question seemed very confusing to me.
But now OP has offered more information. That’s fine.
Basis 0 and 4 seem to be common, defined standards, while Basis 1 is precise. Interesting to note, Google Sheets matches Calc. Beyond me. Al
Sample sheet PriceFunctionCalc.ods
Is there a way for me to make them give the same results?
[1] Compare results from calculating the formula given in OASIS Document Format Specification - 6.12.38 PRICE, with what funtion PRICE() really yields in Calc - if results differ, probably Calc implementation bug
[2] Take formula MS Excel calculates with their implementation of function PRICE() (see PRICE function - Office Support. Implement Excel’s formula in LibreOffice calc and compare result to Libreoffice’s result of PRICE() and formula evaluation.
[3] Compare both formulas from OASIS Document Format Specification and MS Excel.
Is there a way for me to make them give the same results?
No. Not unless you are a developer for Apache or Microsoft. You’d have to modify the applications (or at least one of them).
Why?
Probably bugs in both Excel and Calc.
I haven’t done any real calculations on this kind of thing since my student days (1985-ish), so my judgement is based on observations of terms vs. results, mostly.
The 30/360 ways of calculation (basis 0 or 4) should be pretty close to actual/actual (basis 1). On the sample calculations they are equal to six digits of precision. OK so far.
The Actual/365 (basis 3) should deviate slightly more than the 30/360 methods. Deviation depends on how far away from the February/March transition your settlement/maturity dates are, and whether you pass a leap day.
I have a feeling that Calc is too far off here, but not sure about the calculation. It’s been too long since I actually did any of this. I suspect Calc, maybe both apps, to be at fault.
The Actual/360 (basis 2) should deviate significantly more than the other methods.
Here Excel returns exactly the same as the 30/360 calculations, regardless of choice of settlement/maturity dates. To me that looks wrong. To my eyes, Calc returns a sensible result. I suspect that Excel is at fault.
@Squid1:
Criticism concerning a tool, a predefined routine, or a function implemented by a software may concern one or more of the questions:
Is it useful?
Is it specified in a clear and unambiguous way?
Does the specification meet the actual needs and the reasonable expectations?
Does the tool/routine/function correctly implement the specification?
Are the implementation and the related UI means handy?
Is everything well documented and explained for the user to the full extent of its specified behaviour?
The question “Does it yield the same results as Eciffo SM?” was omitted intentionally.
Judge yourself. You will know what you have to expect. You should check whether the specifiactions meet your expectations.
(To be continued.)
(…continued)
Start with the Open Document Format for Office Applications (OpenDocument) v1.3.
What you mainly need is “Part 4: Recalculated Formula (OpenFormula) Format”, and therein subchapter 6.12 where the financial functions are specified.