Application rules determine how receipts are applied to the unit accounts. Sometimes it is desired that receipts first be applied to the oldest invoices still due on the accounts. Sometimes, it is desired to apply funds first to dues (or rent) then to whatever's left. The application rules allow you to determine how receipts are applied to the outstanding invoices on unit accounts. Orginally, our application required users to actually "apply" payments to invoices while posting payments, but that was very time consuming. Consequently, we developed an application rules plug-in for our ERP application a number of years ago.
The application rules are invoked during the deposit process. When this process is run, all receipts on-hand are first applied to advanced payments then applied to outstanding invoices (and credits). Obviously, if the amount of outstanding invoices due are greater than the payment(s) received then none of the advanced payment is retained; as it's applied to outstanding invoices.
Basic Application Rules
The basic logic is to apply all payments to the oldest invoices outstanding. The principal rules for funds application are:
When applying payments, any advanced amount is added to the receipt amount then applied. In order to do this, when the advanced amount is added, to the advanced invoice, any previous invoice is deleted, and will be created again if an amount is left over to be applied. This is done so the advanced amount will have a date of the most recent payment.
There is great value to this application rules plug-in. Users can:
This helps our users save a tremendous amount of time processing payments. The "Apply Rules" can be configured for your management company as a whole, for a chart-of-accounts type, or for an individual client. Rule granularity is obeyed; thus, if you set up a client rule this will apply first, a chart rule applies second, the global rule applies third, and the default rule (apply payments to oldest invoices first) applies last.
Overview of Rules
The application rules can be granularized to create complex policies required by management companies. Granularization provides the means to assign one set of rules for some clients while other clients use more default rules. A different rule can be created for different Charts or different Clients. Thus, a management company wide set of rules can be configured, another set (or more) can be configured for particular a group of clients with a particular chart-of-accounts type, and another set can be created at the client (HOA) level.
Here's a quick rundown of the various configuration parameters available:
This can have multiple values within this configuration parameter. Each G/L acct# used here dictates the order of invoices that payments are applied to, so if acct# '1010' is entered here then all invoices with G/L acct# 1010 will have a payment applied to those invoices first, then invoices with the next G/L acct# second, etc. After all G/L acct#s are processed then the payment will be applied to any invoice in the order stipulated in field# 002 above.
This field can have more than one G/L acct#. Each G/L Acct# here dictates no amount should be applied to an invoice with this G/L acct#.
The way APPLY.RULES works is all invoices are reordered by the G/L account#s in field# 3 above (that way we payoff from top to bottom). While we're paying off, invoices with a G/L acct# defined in field# 4 above are skipped. So, if a G/L acct# is in field# 4 above, it won't be paid off even though it's also in field# 3.
The G/L account#s used for Unapply and AdvPmt come from the Critical Accounts table instead of from the T/R description codes file.