Historic P/L data does not match current Equity

Environment

Python

Alpaca SDK Version
API v2

Problem

There is discrepancy in my portfolio history data i.e. if I sum the profit/loss for the last month, I get $6752. I started with $100k (paper trading) and now (after 1 month) the Equity shows $116k. So what is right? Where did they get the $116k from? Please check the data in my screenshot and let me know if it makes sense - how can I test my algorithm when I am totaly unsure of the profit/loss it generates.

Paper or Live Tradng?
Paper

Example Code
Get historic P/L:
hist= api.get_portfolio_history(period=“1M”, timeframe=“1D”)

Sum up P/L which does not match current Equity:
hist.df[‘profit_loss’].sum()

Can you re-paste as text? (The table portion.)

There are a lot of weird rows (to my eye). For example, 2020-07-28 shows profit_loss of 0 yet the equity column rose from the previous day.

I’m guessing the profit_loss represents “realized” – meaning a buy+sell pair that resulted in a direct increase in currency/cash – whereas equity includes “unrealized” – meaning a non-cash asset rose in market value.

Yes, P/L seems off:

                                       profit_loss profit_loss_pct	equity

2020-07-21 09:30:00-04:00 0.000 0.000000 100000.000
2020-07-22 09:30:00-04:00 0.000 0.000000 100000.000
2020-07-23 09:30:00-04:00 0.000 0.000000 100000.000
2020-07-24 09:30:00-04:00 1158.360 0.011584 101158.360
2020-07-27 09:30:00-04:00 -120.120 0.010382 101038.240
2020-07-28 09:30:00-04:00 0.000 0.010382 102582.560
2020-07-29 09:30:00-04:00 41.660 0.010793 101282.470
2020-07-30 09:30:00-04:00 -20.120 0.010592 102366.260
2020-07-31 09:30:00-04:00 -12.700 0.010467 102196.050
2020-08-03 09:30:00-04:00 943.670 0.019797 103560.970
2020-08-04 09:30:00-04:00 -238.990 0.017444 103321.980
2020-08-05 09:30:00-04:00 204.750 0.019460 104556.630
2020-08-06 09:30:00-04:00 -163.410 0.017867 104629.920
2020-08-07 09:30:00-04:00 163.060 0.019453 106137.670
2020-08-10 09:30:00-04:00 874.030 0.027848 106405.280
2020-08-11 09:30:00-04:00 69.350 0.028518 106474.630
2020-08-12 09:30:00-04:00 -62.750 0.027912 105314.690
2020-08-13 09:30:00-04:00 -209.780 0.025864 107726.510
2020-08-14 09:30:00-04:00 69.270 0.026524 107795.780
2020-08-17 09:30:00-04:00 1816.130 0.043819 109668.730
2020-08-18 09:30:00-04:00 191.150 0.045638 109859.880
2020-08-19 09:30:00-04:00 194.210 0.047486 112567.800
2020-08-20 09:30:00-04:00 750.680 0.054472 111374.190
2020-08-21 09:30:00-04:00 1104.055 0.064925 116362.475

And I was not able to find proper explanation about P/L vs Equity to be able to explain.
I might be just the “cash” profit, but not sure about it…

I was looking at my paper account for comparison. I’m seeing the same phenomenon. In my data for some days, the PL is definitely not just the profits from resolved (bought then sold) positions – it aligns with the delta in equity from the previous day (bought-then-sold profits + unrealized gain in held positions). On other days I see similar entries to your where I can’t explain (easily) how the profit_loss is calculated.

@hitoshi

I hope at least the historic and current Equity values are correct (as far as I monitored the Equity from day to day it should be ok), so I just calculate daily Rate Of Return by (in python) and hope it is ok:

history_df[‘equity’].pct_change()

I need something like this also in order to measure the Sharpe ratio…

I have found the fill price, in paper trading, to be wrong sometimes (like a few times a month but that depends on your volume) I keep track of the equity price along side what the order says and compare at the eod. Most of the time, if I submit a limit order I use that price and if I submit a market order use whatever the price was at that time (however the latter is a slippery slope)

I have found the fill price, in paper trading, to be wrong sometimes

That seems really broken in the API. Do you see the same problem in Live?

Haven’t seen this in live.

1 Like

@hitoshi It doesn’t make sense to me that Paper would have a broken filled_qty but it doesn’t repro on live. Any thoughts?

Sorry, I might not have been clear, I have only seen this with fill price but I can see how it could happen on quantity as well.

No, you were clear. I had a typo. Apologies for miscapturing your issue.

To be clear, any of the fill parameters being wrong is a serious API breakage IMO. If we can’t trust the API in Paper, it’s odd to expect that we can “just trust” that it will be right in Live. Even if we do trust that it will be fine in Live, I can’t trust that my usage of the API will be fine in Live if it’s built using inputs from Paper that are different in pretty fundamental ways.