I'm building a relational database to model double entry accounting.
Right now it's such that any attempt to enter an unbalanced transaction (where dr != cr) will be rejected; with this restriction, I'm wondering how to handle transfers between bank accounts where a transaction may remain unbalanced for several days until the money shows up in the account at the receiving institution.
Based on an old model I used to track my own finances, what I have is an asset T account called "Transfer" which acts as a go-between from bank account to bank account. This way, when money is sent, a balanced transaction can be entered between the bank account and the Transfer T account, and likewise when the money is received.
Is that a reasonable solution? Or should I remove the restriction of entering unbalanced transactions? Ultimately I'll build an application around this database, which could notify the user of any unbalanced transactions, explaining that transfers will be unbalanced until the money has been received at the other bank, or asking the user to complete the transaction by entering the corresponding debit or credit entry.
One benefit of the "Transfer" T account is that any non-zero balance indicates pending Transfers, but this could also be calculated with a database query in the "unbalanced" scenario.
But I'm hoping for less of a technical implementation answer, and more of a standard practice / best practice answer from people very familiar with double entry accounting. And perhaps any insight into the implications of each solution. For example, is it "bad" to have temporarily unbalanced transactions in the ledger?
Edit: To clarify, when the transaction appears in one account I understand I could immediately debit and credit both involved accounts. The "Transfer" account allows me to avoid having to detect the duplicate transaction once it appeared at the receiving institution. It also saves me from having to find a way to automatically detect what the destination account is.