Introduction

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:

1. If the payment doesn't pay off the account then the payment, and only the payment, is applied to unpaid invoices in the order defined in the application rules configuration.
2. If the payment does pay off the account then the payment is added with any ADV payments and this amount is applied. By using this remaining application balance we make sure all credit memos and advance payments are properly applied to the unpaid invoices.

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:

1. Post receipts and ignore funds application,
2. Automatically post receipts during the deposit process per configured rules, and
3. Automatically post advance payments during the T/R Month-End process.

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:

1. Application of Payments flag.
• 0 - Auto apply only if Payment >= Customer Balance
• 1 - Auto apply using rules in field 2 & 3
• 2 - Don't apply payments at all
2. Date order of Payment application.
   • 0 - Oldest invoice to Newest invoice
   • 1 - Newest invoice to Oldest invoice
3. Order of G/L acct#s to apply Payment to.
   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# '4010' is entered here then all invoices with G/L acct# 4010 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.
4. G/L Acct#s NOT to apply Payment to.
   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#.
5. This flag indicates that the advanced payments, in the T/R module, will be done automatically during EOM processing. A null or zero (0) will allow the user to be prompted, if they have a 6 or greater security privilege.

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.