Patent Application
20100217692
One embodiment is directed to business accounting, and more particularly directed to a rules engine automating business rules.
Procure-To-Pay (“PTP”) is a key business process of any company engaged in the business of trading or manufacturing. Typically, the business events in this process start with the receipt of goods for inspection and the delivery of goods to a warehouse location, followed by the recognition of payment liability for a supplier invoice. The process ends with final payment to the supplier and recognition that the PTP process is complete. There may also be other events such as a return of goods to a supplier, recognition of credit from the supplier for returns or discounts, and settlement with the supplier for credits as part of a reverse logistics process.
These business events are typically processed by more than one business application module of any Enterprise Resource Planning (“ERP”) software. For example, receipts may be processed in an inventory module, invoices may be processed in an Accounts Payable module, payments may be processed in a Cash Management module, etc. Generally accepted accounting principles (accrual basis of accounting) mandates the creation of financial accounting entries when the business event happens. Table 1 below represents a typical chain of financial entries, or a Purchase Order Document (“POD”), showing a business event, the debits and credits to accounts as a result of the event, and an ERP module that may handle the task of recording the financial accounting entries.
Ideally all the receipts made should be invoiced and the balance in the Supplier Accrual account should be zero at the end of the PTP cycle for a POD. However, there could be balances in accrual accounts (i.e., an account that recognizes revenues and expenses when they are earned or incurred regardless of the actual cash inflow/outflow) due to the following possible reasons: not all receipts have been invoiced but the supplier has settled; less than the invoiced quantity was received but the supplier has settled; there is a small quantity/amount difference due to rounding differences across application modules; a receiving clerk mistakenly failed to enter the receipt; an invoice clerk mistakenly failed to enter the invoice from the supplier, etc. One of ordinary skill in the art will recognize there could be many various other reasons why the accrual account value is incorrect.
The balance in accrual accounts should ideally represent only receipts which are yet to be invoiced and invoice quantity yet to be received. However, possibly due to reasons discussed above, the balance may be inaccurate and therefore should be reviewed and reconciled. This task is referred to as accrual reconciliation. Accrual reconciliation involves extracting accounting reports, manually examining each purchase order, and manually clearing balances where there is no major error. The task of accrual reconciliation is thus a non-value adding and time consuming activity.
The valuation of inventory delivered to a warehouse is based on provisional accrual accounting, which uses the price in the POD if an invoice corresponding the POD has not yet been entered into the system. However, the final price paid to the supplier may be different from the one tentatively agreed upon or estimated in the purchase order document. Thus, there is potentially a need to re-value the inventory to reflect the final price paid on the supplier invoice, depending on inventory accounting policies. Also, after the purchase order has been finally paid to the supplier, the un-cleared balance in the accrual account should be cleared and the inventory should be re-valued to reflect the final price paid to the supplier.
Thus, in typical PTP accounting, manual account reconciliation must be performed to clear accrual account balances where the purchase has been settled, and to reconcile an invoice price paid to a supplier that is different from the purchase order price. This manual process can be very time consuming and prone to human error.
One embodiment is a system for reconciling purchase order documents each having an associated accrual account. The system selects a plurality of purchase order documents for which the accrual account is non-zero. The system then filters these purchase order documents by applying a set of business rules. Based on the filtering, a list of purchase order documents is obtained for which the accrual account should be cleared. The system records the list of purchase order documents in a database. The accrual accounts are then automatically cleared.
Systems and methods in accordance with an embodiment are directed to a reconciliation engine for accrual accounts associated with purchase orders. When an organization purchases supplies or products, those products are delivered to the organization's warehouse and a bill of receipt is obtained. This begins a series of business events that cause a series of credits and debits to an account, referred to as an accrual account, that is maintained for the purchase order for those products and subsequent storage in inventory. The reconciliation engine uses a set of accounting or business rules to analyze the purchase order and associated business events to determine if an accrual account can be closed. That is, the balance in the account is cleared and the purchase order is deemed complete. An interface is also provided to reverse the automatic clearance if needed, as well as to adjust accrual accounts manually.
Computer readable media may be any available media that can be accessed by processor 22 and includes both volatile and nonvolatile media, removable and non-removable media, and communication media. Communication media may include computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.
Processor 22 is further coupled via bus 12 to a display 24, such as a Liquid Crystal Display (“LCD”), for displaying information to a user. A cursor control device 28, such as a touch screen or mouse, is further coupled to bus 12 to enable a user to interface with system 10.
In one embodiment, memory 14 stores software modules that provide functionality when executed by processor 22. The modules include an operating system 15 that provides operating system functionality for system 10. The modules further include an accrual reconciliation engine 100, described in greater detail below, and other enterprise resource planning (“ERP”) modules 120. System 10 may further be coupled to a database 17 for storing additional data.
A purchase order document (“POD”) is a record, electronic or paper, of business events and corresponding debits and credits to the associated accrual account that allow organizations to audit the completeness of a purchase order. Accrual reconciliation engine 100 includes business rules 210 for filtering PODs to determine which accrual account that can be cleared based on accounting rules represented by business rules 210. Business rules 210 may be a part of accrual reconciliation engine 100, or may be stored externally such as in database 17 of
Rule A: Business Unit: XYZ
Match All of the following
Supplier: ABC Inc.
Purchase Order Status: CLOSED
Balance in Accrual: Less Than USD 1000
Rule A implies that when a PO is in “Closed” status and the supplier in the PO is “ABC Inc.” and the accrual balance is less than US $1,000, that PO is deemed as completed and finally settled. Thus, any balance in the accrual account is not a true balance and should be cleared and absorbed into inventory cost.
A typical example is that as time passes, the account balance threshold increases. Thus, greater amounts would be cleared for older balances than for younger balances. Another example rule may be:
Rule B
Business_Unit in “XYZ”
Match any of the following
(Item_Category in “123” and PO STATUS=‘FINALLY CLOSED)
(AMOUNT<$2000 and TRANSACTION AGE>3 weeks)
Thus, if the business unit is “XYZ” and the item category is “123, with PO Status as Finally Closed” the accrual account balance should be cleared. Or, if the Business unit us “XYZ”, the balance amount is less than $2000 and the transaction age is greater than three weeks, the accrual account balance should be cleared.
Accrual reconciliation engine 100 further includes an accrual clearing rules engine 220. Accrual clearing rules engine 220 validates PO information from other ERP modules 260, 270, 280 against business rules 210, flags applicable POs as ‘Complete,’ and marks them eligible for clearing. Accrual clearing rules engine 220 may be scheduled to run at fixed intervals of time, at the end or beginning of each day, or on demand. Accrual reconciliation engine 100 further includes accrual clearing accounting engine 230. Accrual clearing accounting engine 230 selects POs flagged as due for clearing and clears the balance in the accrual account as well as re-values the inventory quantity delivered through the PO. Table 2 illustrates example accounting events created by accrual clearing accounting engine 230 in accordance with an embodiment.
The automatic reconciliation performed by accrual reconciliation engine 100 reduces the need to review the accrual balances and reconcile them through manual intervention. However, situations may still occur where such manual intervention is desired. Thus, accrual reconciliation engine 100 allows a user to view the accrual status of POs and take appropriate actions.
In some instances, a new transaction may happen for POs already cleared by the accrual clearing process. A user may thus want to reverse the past automatic adjustment. Accordingly, accrual reconciliation engine 100 allows the user to reverse the automatically cleared accrual balances.
Accrual reconciliation engine 100 further reconciles the value of inventory at the final price paid to the supplier to ensure a true reflection of inventory values. Accrual reconciliation engine 100 automatically creates adjustment entries that revalue the receiving inspection and the inventory valuation for goods in the receiving bay and goods in the warehouse respectively. The inventory is thus valued at the true cost of acquisition, which can be mathematically stated as Invoice Value divided by Quantity Delivered, rather than the cost stated on the PO. Table 3 illustrates the accounting events associated with revaluation:
As disclosed, an accrual reconciliation system in accordance with an embodiment includes accrual reconciliation engine 100 communicating with receipt, inventory, cost accounting, and other ERP modules to obtain purchase order data and determine which purchase orders have an associated accrual account that is non-zero. Accrual reconciliation engine 100 can then apply business rules 210 to the purchase order data to determine which accrual accounts may be cleared, and automatically clear them. Accordingly, the amount of purchase orders requiring the attention and manual intervention of users is drastically reduced. Moreover, the risk of human error in discovering accrual account discrepancies is limited.
Some embodiments of the invention have been described as computer-implemented processes. It is important to note, however, that those skilled in the art will appreciate that the mechanisms of the invention are capable of being distributed as a program product in a variety of forms. The foregoing description of example embodiments is provided for the purpose of illustrating the principles of the invention, and not in limitation thereof, since the scope of the invention is defined solely by the appended claims.
