It's not clear from your question how much of double entry bookkeeping your application will be supporting. Your database is overly constrained when it comes to the various transactions that can occur in full blown double entry bookkeeping.
In particular, there are certain transactions where the debit is split among two or more accounts that receive the debit, or the credit is split among two or more accounts that receive the credit. These transactions represent unusual transactions in your case, if I understand your case correctly. But you may find it necessary to support them.
To illustrate the above, consider when a homeowner makes a mortgage payment. In the homeowner's books the debit side of the transaction will be split between Mortgage Principal and Mortgage Interest. Mortgage Interest is an expense, while Mortgage Principal is a liability, which the mortgage payment reduces.
Again, You may or may not need to support split transactions.
Given that this is your first time out with DB design for double entry bookkeeping, it may well be worth your while to bone up on the subject, on order to avoid delivering a substandard product. There are many excellent books on this subject. In addition, if you want to see some accounting databases that are freely available, you can go to http://www.databaseanswers.org/data_models/ and look under data models for accounting.
I'll give an oversimplified summary here.
Many double entry bookkeeping databases split transaction data into two tables, which I'll call TransactionHeader and TransactionDetail. TransactionHeader has columns for data that occurs only once per transaction, such as TransactionID and Date. TransactionDetail contains data about a transaction as it affects just one Account, and there are at least two transaction details for each transaction. Data in TransactionDetail includes TransactionID, ItemID, AccountID, DebitAmount, and CreditAmount.
Split transactions have more than two TransactionDetails associated with them.
The sum of the credits must equal the sum of the debits for any transaction. Sometimes, this can be expressed as a database constraint. Other times, the programmer is forced to maintain this aspect of data integrity in the application.
Some database builders collapse CreditAmount and DebitAmount into a single column called Amount. Credits are entered as negative amounts. If you do sums on groups of items, the right thing will happen. There are, however, downsides to taking this shortcut. I'll leave it up to the books that teach you about bookkeeping databases to fill that in.
Again, if this is overkill in your situation, feel free to disregard this answer.
Hopefully, no one will come along later and attempt to use your databases for purposes it was never intended to cover. But I have seen this happen in the real world, with disastrous consequences.