Over the past weeks, I've implemented a change in the way payments are
being recorded: batch payments are now recorded explicitly (instead of
implied) and payments entered into the invoice screen are now recorded (as
opposed that they were not recorded as payments, but "just" lines on the
The next step in my improvement plan is to use the new payment information
To understand the problem domain, there's a bit of context to be explained:
technically, every invoice being paid in a payment causes its own line in
the Bank GL account. These lines are grouped using a payment
identification. Now that all payments are being correctly recorded in the
database, we can tap into that information to summarize the bank
reconciliation view: We can show payments as a single line.
Where we're coming from is different: we used to aggregate lines on the
Bank GL account by various fields (reference, counterparty, source
reference, date, transaction type, mostly). The method we used to use,
caused two payments by the same customer - entered without a source
reference number - to be aggregated into a single reconciliation line. On
the other hand it was impossible to post small corrections to payments
through the GL: because the aggregation takes the transaction type into
account, GL transactions and payment transactions (AR/AP) can't be
aggregated into a single reconciliation line.
I was thinking that the reconciliation could be changed to use this
Aggregate into single reconciliation lines (so as to reconcile with a
single bank transaction):
* Payments and GL transactions on the same date with the same 'reference'
* GL lines with the same date and same 'source' (source reference number)
-- if the gl lines couldn't be merged with a payment
This business rule allows reconciliation - as single reconciliation lines -
* Reconciliation of payments *with their GL corrections* as a single
* Reconciliation of payments (without GL corrections)
* Reconcilation of GL-entered lines with the same source code reference
* Reconciliation of GL-entered lines individually (when no source code
reference is entered)
Is this what we want?
It's wildly different from the criterion we currently use, where we
aggregate all lines on the bank account, into lines where the
* Transaction type (ar/ap/gl)
* Reference (AR/AP: internal eca ID; GL: transaction's "Reference" field)
* Voucher number
* Source reference number (Source field of transaction line)
* Memo field content (transaction line Memo field)
Note however, that in the current situation, there isn't a concept of
"payment" in the database at the moment; transactions posted using regular
and batch payments receive the same values for Date, Transaction type,
Reference, Source reference number and optionally voucher (for bulk
payments). Concluding: the old rule mostly aligns with payments, but on a
different basis and may aggregate multiple payments into one.
When we hash out the question above, I have a follow-up question of how the
reconciliation process should work from a business process perspective.
Let's try to hash this one out first.
-- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.