Sure, different organisations have different ways of representing the data but ultimately both sides need to capture the same basic data otherwise how can they come to an agreement over a transaction? At a basic level they need to record:
- that a transaction took place
- the items x y z were bought and their prices
- the payment terms
Most of the data will initially be derived from a static data system, e.g. address of me and address of counter-party, payment terms etc. Other data will be derived from preceding documents. E.g. an invoice is populated using a purchase order.
The transaction data would be held in Corda as a state object - ultimately it ends up in a SQL DB, which is what most ERP systems use as a persistence layer. If they need any additional data they can add columns in a table to store it.
Now, when either side needs to report the transaction then they take the Corda state object and apply the rules of the respective accounting frameworks which they are bound by. Alice may need to use IFRS where as Bob needs to use US GAAP. This works fine as we can implement a function which takes a corda state as input and produces accounting journals as output. IT would need to take as a parameter some kind of rules which determine how the accounting journals are created.