StockIssuance -- does cost_basis make sense here? Is it the per-share basis or total?

[pjohnmeyer]

https://github.com/Open-Cap-Table-Coalition/Open-Cap-Format-OCF/blob/234f5ea279f849da4cdb75b2306c6cc743dd3d0a/docs/schema/objects/transactions/issuance/StockIssuance.md

Currently we have share_price ("The price per share paid for the stock by the holder") and cost_basis ("The cost basis for this particular stock") both have required fields on StockIssuance. I admit I have a somewhat limited understanding of Cost Basis, but I do understand that it can change over time for various reasons.

If it is meant to be the point-in-time cost_basis specifically at the time of issuance -- isn't that always the same as quantity * share_price? Or do additional considerations come into play?

Also, the documentation isn't clear: is this the per-share value or the total value for the issuance?

[JSv4]

Hey @pjohnmeyer, talked to some folks about this. Most of the time, the cost_basis on a per-share basis will be the share_price paid * quantity issued, whether via cash or some other consideration. There are situations, I'm told, where that is not the case. I think it's best to keep this field at the time of issuance. For almost all implementations, it will make sense to set cost_basis equal to share_price * quantity, but it will be good to be able to track instances where that's not the case if they arise.

As for whether it's per-share or total value for the issuance, I think it should be the same as the consideration (which, I see, is also not clearly documented). Either per-share for both or total value of the issuance for both. I think, since these fields are on an issuance, which includes multiple shares, and neither field has an explicit share_ prefix or _per_share suffix, let's go with the total value.

[JSv4]

TWG Call Notes:

We need to be careful about providing information to the best of our information that might not be technically correct. May need some further discussion and clarification from tax folks @ GD.

[pjohnmeyer]

@JSv4 would you be opposed to a PR that marks this as a possible PreReleaseOmission until this is resolved?

[JSv4]

@pjohnmeyer, no problem. That makes sense to me.