In the history section you refer to the "Greek empire". Is that the Byzantian empire (the eastern part of the Roman empire after the split) or the system of Greek city-states or Alexander's empire from before Roman conquest? An approximate timing (to the precision of a few centuries) would help.

As for the substance: Am I right in the interpretation that if all parties keep the signed receipts and recreate their ledger entries from those when they need them, they are safe? In the ePoint system, this is precisely what we do: the signed receipts are on disk, the assets/liabilities databases are constructed from scratch after starting the issuing server. Same for the client software.
During the auditing process, the books are compared using standard accounting techniques, but from a computational point of view, there's no point in archiving anything in addition to the signed receipts, right?

Regarding triple entry, been there done that.

http://www.google.com/search?q=%22triple+entry%22+site%3Aledgerism.net

> Comments:
>
> In the history section you refer to the "Greek empire".
> Is that the Byzantian empire (the eastern part of the
> Roman empire after the split) or the system of Greek
> city-states or Alexander's empire from before Roman
> conquest? An approximate timing (to the precision of
> a few centuries) would help.

I have no idea which it is, I'd have to go back to the source of that comment to figure it out. But a good comment!

> As for the substance: Am I right in the interpretation
> that if all parties keep the signed receipts and recreate
> their ledger entries from those when they need them,
> they are safe? In the ePoint system, this is precisely
> what we do: the signed receipts are on disk, the
> assets/liabilities databases are constructed from
> scratch after starting the issuing server. Same for
> the client software.
> During the auditing process, the books are compared
> using standard accounting techniques, but from a
> computational point of view, there's no point in
> archiving anything in addition to the signed receipts, right?

That's it! Do you have any references I can cite to your designs or work as being similar or equivalent? That would help a lot as showing that others have independently arrived at the same conclusions adds a lot of weight.

It looks like you've maybe travelled the same path on a lot of things. We should probably get together and compare these things in more detail and start thinking of merging the good parts?

Some links on Todd's stuff to read:

http://ledgerism.net/GLT-GLR.htm
http://ledgerism.net/fbc.htm
http://www.ledgerism.net/STR.htm
http://ledgerism.net/rootledgerXML.htm
http://www.byte.com/documents/s=485/byt20001103s0001/index.htm

second post on my latest blog:

What is triple entry booking or accounting. I need to explain it to my grade 12 accounting class for an assignment and I can't find anyone but you guys taking about it. If you could explain it to me or tell me where I can get infomation on it I would be forever grateful.

Thank you

Finally, my review of Todd's work (3rd version!) In short, we are on the same page, albeit I think that Todd's on the top looking down and I'm at the bottom looking up. Here's a more detailed comparison, URL by URL (and you can click on my name to get there!)

========================================
http://ledgerism.net/GLT-GLR.htm

>> Triple entry accounting is this: ....
>> When you POST, the entry is stored in your internal GL
>> (i.e., your GLT, if you have split your ledger, which
>> is my thinking) just like in the past.

So far no change.

>> But it is also
>> submitted to the triple-entry table in whatever STR
>> system you choose. Perhaps your own STR server, such as
>> the STR module of your GL. Or perhaps it is a big STR
>> server out at Exodus or your ISP or a BSP.

OK, so there is an intermediary, who I call Ivan.

>> ... The STR diligently forwards the entry to the
>> reciprocal party.

Again, no change.

>> If the reciprocal party is interested in integration,
>> they will reply to the transaction sent by the STR, and
>> optionally, complete their private Stub.

This is what you call the pattern or the "commercial transaction". At this stage our notions intersect at the simplest possible example of this which is the payment as described in the paper. It lacks the "optionally complete and return" part but there are reasons for that and we'll return to it.

>> That is triple entry. STUB - SHARED ENTRY - STUB.

OK, so for me and my example, this is

RECEIPT - RECEIPT - RECEIPT

and even if we include the extension to patterns, I'd still be looking for that script.

>> This is a sub-ledger, folks.

This I didn't understand. Are you saying that the 3 entries above in triple entry form are a subledger? To me they are an entry in a subledger row perhaps, but I'm not an accountant so may be missing the subtelties of the point.

>> Your work is done, if you trust your STR's stewardship
>> of data.

Not in my design :-) ... as the Receipt is fullsome and present in all three parties. The sig arrangment precludes changing the data or forging new ones, and the redundancy solves loss. It's an open and interesting question as to whether we'd enable that closed loop in more complex patterns like that which you are looking at.

========================================

========================================
http://ledgerism.net/fbc.htm

Your FBC I see as further away. My Ivan specifically plays a part in the transaction, whereas your FBC strives to be neutral storage only. Although:

>> STF files serve two purposes: they are the message
>> format for communicating transactions between parties
>> and they are the persistent storage memorializing the
>> transaction once completed.

This brings up the core or criticality of the messaging need - I believe if we think more in terms of providing a reliable messaging infrastructure then things fall into place. In fact, I think it is futile to talk about more complex patterns until the reliable messaging infrastructure is chosen. As we have not done that, then we can't do the patterns. (By this I mean, email is not good enough to support this idea; we need something bette
r. Hence my long project over the last 4 years to add this to Ricardo.)

============================================

============================================
http://www.ledgerism.net/STR.htm

which you list in STR as point 3. As an aside, Ricardo now does 1,2,3,4 in principle at least. We have implemented a full IM/chat system called Rafi's in to Ricardo, so things like patterns can be layered over the top of reliable IM and payments ... If we add easy coding up of requests in some form, then I think evolution of the higher patterns will follow in due course.

Your notion of "the STR is capable of recording any type of atomic business transaction" I think remains an open question for me. Fascinating though it is, I remain stuck at the bottom of the page, building and looking up :)

============================================

OK, this completes for now my review of those links that I posted above. Hopefully I've captured your meaning and will try and integrate it in.

Hi

I had the pleasure reading your article "Triple Entry Accounting"

As I am a technology knowledge transfer advisor , that including the financial system auditing in the paperless society .

Your article added a lot of technical points to my own knowledge and it worth to confirm that the triple entry accounting and modules INTEGRATION is the only way to have a very strong evidence for the financial auditors.

My questions are:
1. where AICPA and IFAC ,why they are insisting to ignore such important approach.
2.do you have a skills map for the triple entry accounting ??

Your feedback would be highly appreciated.

Dr. Fekry Fouad
Professor
0020105253244

> Hi
>
> I had the pleasure reading your article "Triple Entry Accounting"

Thanks!

> As I am a technology knowledge transfer advisor , that including the financial system auditing in the paperless society .

OK. That's one area where we are at, creating the ability to create a sustainable and openly audited system on the net. Of course, paperless :)

> Your article added a lot of technical points to my own knowledge and it worth to confirm that the triple entry accounting and modules INTEGRATION is the only way to have a very strong evidence for the financial auditors.

I think so!

> My questions are:
> 1. where AICPA and IFAC ,why they are insisting to ignore such important approach.

I don't think they know as yet. Part of the reason for writing the paper is to get the ideas down in a form that they might be interested in. Next step is to finish it off (I still have to work very hard to integrate in the work of Todd Boyle and also Lynn Wheeler.) Finally, I need to find a place to publish the paper. As I'm not really up on the accounting world as an institutional approach, I'm keen on suggestions.

> 2.do you have a skills map for the triple entry accounting ??

Hmmm, I am not sure what you are asking here. Do you mean ... what skills are needed to implement it? You could start by reading the paper Financial Cryptography in 7 Layers, which proposes that there are 7 big skills areas:

http://iang.org/papers/fc7.html

Or, could you give me an example if I've misunderstood?

> Your feedback would be highly appreciated.

Thanks again!

Dear Iang

Thnaks for your feedback.
Re the skills map , means the skills that should be given to the accountants and auditors to be able to audit the paperless systems , also paperless systems is not a batch systems but it is web based systems , so all the documentary evidence will not be available , and the financial auditors msut have a proper sills to deal with the digital evidence.

Hello,

I am the Events and Membership Coordinator at the Law Council of Australia. We are hosting a national summit on the future of the legal profession in September and Ian has been recommended to us as a potential invitee.

Could you please provide me with Ian's contact email so I can I can send through the invitation.

Thank you,

Beth