Hi, 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 invoice transaction). The next step in my improvement plan is to use the new payment information in Reconciliation. 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 business rule: 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 - of: * Reconciliation of payments *with their GL corrections* as a single payment line * 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 differentiator is: * Date * 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. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.