Would a company experiencing issues managing purchase orders and invoices benefit from corda?
I’m new here.
The value is in a trust based ledger system, that can be controlled via trusted notary’s. It assumes an exceptionally high need for accuracy and audibility over a system that may not trust all input.
Without knowing your specific use case, I would say that it’s much more likely that traditional billing and invoicing software would be the solution to that specific case.
It does seem possible that billing and invoicing software could benefit from Corda if complex needs were present. But I wouldn’t roll it in from scratch if it didn’t satisfy those complex use cases.
Unless we have cash on ledger, Corda is probably not the solution for billing.
Corda would be an ideal platform to host an accounts receivable / payable application. Each document: purchase order, invoice, goods received note etc. would be modelled as a state with accompanying contract. The various reconciliation steps required in traditional AR/AP processes are not required as with corda everyone is guaranteed to see the same view. Likewise with periodic supplier / customer ledger reconciliations.
For large (audited) companies, you can then rely on the ledger to perform procedural financial audits. Producing exception reports for auditors is much easier than performing sample based substantive testing. Controls testing over the platform will still be required however but as everyone uses the platform we only need to test one version of the software and everyone gets the controls assurance. Audit a multi-billion dollar market but the barrier to entry is probably too high for a start-up.
Probably partner with a consulting firm.
Remember that the infrastructure required to perform this automatic audit will have to be robust enough for auditors to rely on. It will take a long time to get to that stage and that’s just building the tech. Convincing people it will work is the other hurdle.
@roger That is true. Here in Jamaica it will be difficult, not to mention that the technology is nascent here and only I and a few others are aware of it. Do you think r3 has the necessary strategy to aid in adoption and scaling?
If the issues are to do with integrating PO/invoice systems of two organizations involved in the purchase/iinvoice, then bringing corda to the equation might help.
The current practice( typical): Both organizations involved in the PO/Invoice maintain the details( facts) related to the PO/Invoice on their own systems. Also typically contextual information associated with the PO/Invoice will be very different in both the organization. When there are mutually agreed minor changes/amendments there is no single common/shared place to record/refer the facts. This makes it error prone( or change resistant).
If there is value realizable by recording the facts of PO/Invoice in a common/shared place, then corda’s ledger technology is a candidate for implementing the same.
That is why I said there is benefit if inter-organization integration is the problem being addressed.
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.