Hi Gerry, it's late but I'll try to keep my mind clear.

>What is the "primary key" ? It's a compound key: Client and Invoice (in the case of AP/AR). I imagine you could use an "IDENTITY" field (from somewhere), but I consider this particularly User unfriendly, and in any event would always require a join even to do the simplest of reporting.

I suggest that you use surrogate primary keys, i.e. these keys mean nothing to the end user and in fact they don't usually appear on listings. Their only goal is to uniquely identify records. So you don't need compound keys.
Another benefit of surrogate PK is speed on updates. For example: you might think on using the account number as the PK in the accounts table, it makes sense since this number has to be unique; but what if the user wants to change the number in the middle of the fiscal year? You can say that is simple, referencial integrity will take care of this casacade update. But what if the user wants to change a whole group of accounts (no uncommon)? given that the accounts table can be linked to no less than 5 large tables, this update can take pretty long. With surrogate PK the update is made instantly.

>
>>In the transaction table you have all you need: client number, dates, transaction status, ... but you don't need this info in the accounting header (or details) table.\
>
>What came first ? The "transaction" or the "accounting" record ?
>In the case of a cash receipt (for example), the accounting record (the JE) IS the "transaction"; ie. The "Cash Receipt Journal".

Tha transaction always comes first. The Journal is not a transaction, the Journal is only a way to reflect the business life in a structured way.

>
>There is no separate process where "cash receipts" are entered (into something), and then that "transaction" is used to generate "accounting" record(s). In which case, where is the Check # and Check Date stored ?

IMHO you should create tables for payments, be it cash, credit card, check or whatever. This is a vital table in your application.

>
>And what of the case where a single check is used to pay multiple Invoices ? Is the user expected to enter / view a number of (obscure) "primary keys" in the distribution items ? Or do we now always join the detail lines also ?

You can do several things on the programming side, none of them being obscure. For example you can put the check number into each invoice, and then join them when the user wants to see payments; or you can generate a many to many table to link payments with invoices. It's up to you.