Understanding the Accrued COGS Reconciliation Process

Note: This explanation of the accrued cost of goods sold (COGS) assumes that you understand the relationships between aACE inventory lot, usage, and transaction records, as well as unallocated inventory usage and the COGS reconciliation process.

Unallocated inventory usage represents the use of a product that cannot be accurately accounted for as a cost of goods sold (COGS) entry in the GL because an inventory lot cannot be found. However, not accounting for the cost of this usage in some way carries the immediate risk of skewing your financials. In addition, after the underlying inventory problem is resolved, the COGS reconciliation process may not find the cost until a future month. This creates the possibility for financials to be distorted for two months:

  • Sales accounted for in the month the order was invoiced
  • Cost accounted for in the month aACE finds an available inventory lot

The accrued COGS reconciliation process minimizes the potential impact of unallocated inventory usage by creating temporary entries in the GL for the estimated COGS. These entries are automatically reversed once the true cost is found. This means that the sales and cost can be accounted for in the same month, and only the net difference between the estimated cost and true cost — generally a small value — will appear in the future period.

aACE Assumptions about Workflows

When unallocated inventory usage exists, aACE assumes that the data associated with the usage transaction is correct. For example, if a shipment to a customer results in unallocated inventory usage, either the shipment is incorrect or else some other data is incorrect (e.g. a beginning balance entry). The accrued COGS process presumes the shipment record is reliable in this case, since a team member recording a shipment they didn't ship is less likely than the other possible reasons for the discrepancy.

Accrued COGS Process Walk-thru

Using a sample inventory product, we'll trace these three aspects of the accrued COGS process:

  1. Inventory Usage
  2. Accrued COGS Entries
  3. Accrued COGS Reversal

Inventory Usage

For this example, suppose a sales order for three printers ships at the end of a month. This creates an inventory usage record, showing that three units have been used. The COGS Allocation section shows that all three used units are still unallocated.

Accrued COGS Entries

Suppose this product doesn't have an inventory lot with a balance for Current Inventory. When the Generate COGS Reconciliation automation schedule runs, the COGS reconciliation process cannot allocate the inventory usage to an inventory lot. 

However, the accrued COGS reconciliation process will help account for the expense of these units. The accrued COGS value is the unallocated quantity * estimated unit cost. This value is credited to the item's inventory GL account, and an equal value is temporarily expensed to the Accrued COGS GL account (see below for details).

Accrued COGS Reversal

Suppose that in the next month, an incoming shipment is entered and an inventory lot for the printers is created. The unit cost associated with the purchase order is slightly higher than the estimated unit cost.

The next time the COGS reconciliation process runs, it pairs the unallocated printer usage to this lot. The inventory lot quantity is depleted, then the value is both credited to the item's inventory account and expensed to its cost of sales account.

When the accrued COGS reconciliation process runs again, it identifies that inventory usage has been allocated. It reverses the accrued COGS GL entries, debiting the accrued COGS value to the item's inventory GL account and crediting an equal value to the Accrued COGS GL account.

Walk-Thru Summary

The transactions for this example can be reviewed in the General Ledger, where we can see the "net" inventory credit and cost of sales debit. In the first month, the inventory's estimated value of $300.00 was credited to the inventory account and debited to the accrued COGS account.

In the following month, the inventory's actual value of $309.00 was credited to the item's inventory account and expensed to its cost account. In addition, the accrued COGS entries were reversed. The net change to the inventory and expenses for the second month is $9.00. This small net difference between the estimated cost and true cost is all that appears in the second month's financials.

When reviewing both months in the General Ledger, we can see the relevant transactions: a) the net credit to the inventory is $309.00 (i.e. three printers at a true cost of $103.00), b) the true cost is expensed, and c) the accrued COGS entries are fully reversed.

For the above screenshot, the numbered entries represent:

  1. The initial June accrued COGS
  2. The July COGS
  3. The July accrued COGS reversal

Setting Up Accrued COGS Functionality

To get the most benefit out of this feature, we recommend setting up a separate account for accrued COGS.  This can help you identify problem areas in your workflows — when a balance appears in this account, it can be a signal for your team to audit / review the respective products.

If you don't specify an Accrued COGS account in your accounting preferences, then accrued COGS values are debited to the cost-of-sales account associated with each line item code.

Your system administrator can create a specific Accrued COGS account and select it for use:

Create an Accrued COGS Account

Add a new detail account to the Chart of Accounts, using the following information: 

  • Record Type — Detail
  • Header Account — Cost of Sales
  • ID — An appropriate number under the Header Account number
  • Name — Accrued COGS

Select the Accrued COGS Account for Use

  1. Navigate to Menu > Accounting > Preferences > Chart of Accounts
  2. In the Expenses section, click the Accrued COGS field and select the account you created.
  3. Click Commit Updates.

Running the Accrued COGS Process

The accrued COGS reconciliation process typically runs as part of the Generate COGS Reconciliation automation schedule, but can also be run manually. 

Accrued COGS Process Automation

The Generate COGS Reconciliation automation schedule first runs the COGS reconciliation process, then the accrued COGS reconciliation process immediately after. These automated entries always use the current date for the resulting General Journal entries.

Your system administrator can customize the automation schedule, following the guidelines noted in Understanding the COGS Reconciliation Process

Manually Running the Accrued COGS Process

If you execute this process manually, remember to first run Generate COGS Reconciliation (available in the same GJ Actions list). If you run the Accrued COGS Reconciliation process without running the COGS Reconciliation process first, it may create accrued COGS entries for inventory usage records that could be allocated during the COGS reconciliation process. Conversely, if you run the COGS Reconciliation process without running the Accrued COGS Reconciliation process, your financials may become skewed by the sales and costs from unallocated inventory usage being accounted for in different periods, as mentioned at the beginning of this guide.

  1. Navigate to Menu > Accounting > General Journal.
  2. At the list view, click Actions > Generate Accrued COGS Reconciliation.
  3. If applicable, enter the Limit-To Date (see below for important details), then click Yes.

Limit-To Date

The Limit-To Date allows you to backdate an Accrued COGS Reconciliation:

  • Limit-To Date used — The process uses the specified date for the General Journal entry. It considers all inventory usage records dated on or before that date. For this reason, including a Limit-To Date lengthens the process significantly and can tie up your machine for systems with large data sets. We recommend starting the process at the end of the day when you leave your desk.
  • Limit-To Date blank — The process uses the current date for the General Journal entry. It considers onlyinventory usage records that are new or have been changed since the last time the process was run. For this reason, it runs much faster, but for larger data sets it may still slow down your machine.