Purchase Order Accounting

Purchase order posting is a very common process in a business and is done on a daily basis.

The financial impacts of the postings, therefore, form a very important aspect for a business.

Postings happen only once the Receipts are posted. Confirmations and registrations do not have any physical or financial impacts in the system.

Product Receipt: A receipt is what confirms that the Items (stocked, tangible items) have been received into the inventory/ stock. Once the Items are in, only then there are impacts to the Ledgers. 

When a product receipt is recorded for a stocked item, two accounting processes take place:

One accounting process creates an accounting entry for the accrued liability. The accounting entry amount is for the received quantity of the stocked item, multiplied by the currency amount per unit for the purchase order. In the following example, ### denotes the currency amount of the accounting entry.

Debit Purchase expenditure, un-invoiced ###

Credit Purchase, accrual ###

Another accounting process accounts for the cost in inventory for the received quantity of the stocked item by crediting the expenditure ledger account and capitalizing the cost in an inventory asset ledger account.

Debit Product receipt ###

Credit Purchase expenditure, un-invoiced ###

Purchase Invoice: When an Invoice is posted, it indicates that the Vendor has issued a bill for the goods that have been transferred. A Vendor Invoice is what creates the liability towards the Vendor.

When a vendor invoice is recorded for a stocked item and accounting entries are created, two accounting processes take place:

First, the accounting entries on the product receipt for accrued liability are reversed. The amount that is reversed is based on the quantity of stocked item on the vendor invoice that is matched to the product receipt. Then, the accounting entry is created to record the liability for the vendor invoice. .

Credit Purchase expenditure, un-invoiced ###

Debit Purchase, accrual ###

Debit Purchase expenditure for product ###

Credit Vendor balance (Accounts payable) ###

Second, the accounting entry on the product receipt that records the inventory cost is reversed. The amount that is reversed is based on the quantity of the stocked item on the vendor invoice that is matched to the product receipt.

Additional account entries are created to record the inventory cost under a new inventory ledger account classification.

Credit Product receipt ###

Debit Purchase expenditure, un-invoiced ###

Debit Purchase, product receipt ###

Credit Purchase expenditure for product ###

Notes:
Where the Inventory runs on Weighted Average costing, there is a chance that the Vendor accounts and the Inventory accounts are posted with different amounts. These differences are in tandem with the Calculations that the system does for arriving at the Weighted Average cost of the Item.

The Budget Paradox

Every situation today has a paradox to it. A paradox is a statement that apparently contradicts itself and yet might be true (or wrong at the same time). Budgeting is no different.

Budgeting, as defined, is a process wherein a certain amount of resources (funds) are allocated to each expense. This ensures that the resources are optimally utilized and there is no dissatisfaction.

The Paradox, however, makes a different statement:

There needs to be a certain level of dissatisfaction within an organisation before it starts to examine its current situation and search for alternatives. It seems that some momentum for change needs to exist before changes are considered

What it means is that there has to already be some under/ over utilized resources, which are resulting in in-satisfactory outputs. Only then will the organisation think up of adding a budget, knowing very well that if they do not use budgeting, they will end up in a situation depicted in the former statement.

Well, it  seems more like human nature to do such things... In short, the paradox says that Organisations will dig the well only after there is a severe short supply of water and while they are at it, they will face all the more resource crunch. All this, when they are fully aware of the depletign water supply :P 

Project Module - Accounting

Project Cycle
 

·         Raising a Project Quotation – with estimates of Items, Expense and Hour

·         Converting Project Quotation to Project, after contract

·         Item Requirements

·         Posting Consumption and Recognizing costs

·         Recognizing Revenue

·         Invoice to Customer

      Raising Project Quotation:

Before creating a project in the system, a project quotation is raised. This is again based on the business requirement of the firm.

A Project Quotation includes the estimates for Raw materials (items), Time (hour) and Overheads (expenses) along with the costs and revenues. Once the terms are agreed at, the quotation is converted to a Project.

Converting project quotation to Project

Once the quotation is approved, a Project is created. Projects can be directly created in the system as well, based on the requirement.

When a Project is created from a quotation, all the details from the quotation are copied into the Project

Items have to be purchased before consumption. (Otherwise is also possible if Negative Inventory is allowed. However, it is better to have physical inventory before consumption to recognize costs appropriately)

Hour and Expenses can be directly booked in the system

Item Requirements

The item requirements are fetched from Project Quotation where applicable. In case of directly creating a project, the Item Requirements must be defined.

Path: Project Management >> Common >> All Projects >> Select Project >> Item Requirements in Manage tab

Purchasing Items: Item Requirements >> Functions >> Create Purchase Order

Once PO is created, Confirm > Receive > Invoice the PO

The Accounting:

Inventory dr

To Accounts Payable (vendor account) cr

Posting Consumption and recognizing costs

Item Consumption happens through a Project Sales order. Whenever a Purchase order is created for item requirements, a Sales Order is simultaneously created for the Project.

Considering that there is no requirement to Purchase the Required item for the Project, a Sales Order is created when the Item Requirements are raised in the system.

To view the Sales Orders, go to Project >> Item tasks >> Sales Orders

Here the Sales Order has a status “Open Order” and Type “Item Requirement”. Further, all options for confirmation, picking, packing and invoice are disabled in the form. This is because the SO is not actual sales to Customer, but a consumption posting for the Items to be consumed for the Project.

Note: Sales Orders of type “Item Requirement” can only be created and posted from within the project and not otherwise.

The item consumption is posted in the system by posting a packing slip for the respective sales order, from within the project.

Path: Item Requirement >> Posting >> Post Packing Slip

Once the Packing Slip is posted for the Item, the Status of the SO changes to Invoiced. Also, there is no Unit Price or Net Amount on the Lines for the Item Consumption, since this is not booking any liability to the customer.

The Accounting:

Project Cost account dr

To WIP Cost account cr

WIP – the concept:

WIP is a system parameter. It indicates costs/ revenues that have not yet been accrued. In the case of a Project, the entire cost is not consumed at once and it is periodic, until such point that the revenue is recognized. When the Revenues are recognized, the costs are recognized at actuals.

In case the business does not wish to have a WIP account, the costs can be directly mapped to the actual Cost account.

Sales Category:

Sales can either be processed for a Sales Category or an Item. Each Category is associated with one or more Items.

While processing a Sales Order, user can either process for a sales category or for an Item. When a Sales Category is updated, the system does not allow to select the Item. However, when the item is selected on the Lines, the sales category is auto-populated where applicable.

The Accounting – for Category sales:

Customer account dr

To Sales Category account cr

The Accounting – for Item sales:

Customer account dr

To Item Sales account cr

Recognizing Revenue

Revenue recognition is a process wherein the Business decides to “recognize” or identify the revenues in the system. It is different from actual sales in the sense that there is no Invoice posting that happens at recognition. It is a system process for businesses to conclude as to the revenue that the project will bring. It is a kind of Estimation of revenues.

The Accounting:

WIP Revenue account dr

To Actual revenue account cr

Revenue estimation can be done for the entire revenue or for a part of the Revenue based on the project completion and the milestones for the project.

Let’s say that the total revenue expectation for the project is $100,000. This entire revenue can be recognized at once or in slots (equal or otherwise)

Estimating a 10% revenue will create an entry of $10,000 against the project. Estimating at 50% will create an entry of $50,000 against the project.

Invoice to Customer

The customer invoice is where the actual sales is posted in the system for the project.

The Accounting:

Project Customer (person or organization) dr

To WIP revenue account cr

Happy Learning..

Budgeting in AX 2009 - Overview

Budget Allocations

AX has the ability to use predefined allocation rules to perform generated allocations. Generated allocation is the distribution of posted or fixed amounts to combinations of destination accounts and dimensions at any time, for which system generates new Journal entries distributing the amount based on an allocation formula.

Allocation can be set by various methods in Ax, which includes:

- Basis

- Fixed percentage

- Fixed weight

- Spread even

The Allocation process in the system is divided into 3 segments.

• §  Ledger allocation rules definition
• §  Process Allocation request
• §  Allocation Journal.

Ledger Allocation Rules definition: - The first step in allocation is to define the allocation rules.

Creation of allocation rules requires the allocation code, allocation validity as Start Date & End Date. Then, select one of the allocation methods as fixed percentage, Basis, Fixed Weight, Spread even.

After selecting the allocation method, define the Rules for the Source Ledger account. Source Ledger accounts and dimensions can be selected where the expenses has been incurred.

Define the destination account & dimensions where the amount needs to be allocated. Also define the actual percentage or Basis based on which source amount should be allocated to destination. Once destination is defined the Ledger allocation rules are completed.

Process Allocation: -Once the Ledger Allocation rules are defined, the unique rule code will be generated. Refer the rule code in process allocation request to process the allocation entries (based on the allocation rules the system will reallocate the cost to the respective department.)

After selecting the rule code, provide start date and end date of rules and reason codes with remarks. Process the Allocation request and this generates the financial entries in allocation journal.

The allocation process collects one or more values from a source data record and distributes the totals of the values to one or more accounts or account and dimension combinations according to an allocation rule that is defined using the Ledger allocation rule form.

Allocation Journal: -Allocation journal shall show the entries passed by Process Allocation step. System would generate the entries on running the Allocation request. System shall reverse the Source Ledger a/c and book the entries against destination ledger accounts as per the allocation rule.

Budgets

Budgets are defined for each Chart of Accounts dimension wise, where dimension can be a Category/cost center/department/projects/sub department which are identified as Dimensions.

AX supports budgets to be created at the General ledger level. The budgets are maintained at the chart of account level with relevant dimension and the variance analysis will be made at the chart of account level.

Sales and Purchase Budgets:

The budgeting for sales and purchases is carried out in the Accounts Receivable & Accounts Payable module and the same will be transferred to GL. However the accounts that are affected during the transfer are only the Sales revenue accounts and the purchase inventory accounts.

The sales and purchase forecast can be entered by quantity and amount and the allocation keys will be defined to split the amount over a period of time when the forecast are transferred to GL budgets.

Budget Revisions:

There can be scenarios where the budgets are prepared and approved for the complete year, however the budgets can be revised as per the requirement. The existing budgets can be modified or a new budget created with the revised figures. 

Price Tolerance

Price tolerance defines the percentage by which the invoice net unit price can exceed the purchase order net unit price, and still be considered within the allowable tolerance for invoice matching discrepancies.

Invoice matching is the process of matching vendor invoice, purchase order, and product receipt information. Differences among these documents are called matching discrepancies. Matching discrepancies are compared with the tolerances that are specified. If a matching discrepancy exceeds the tolerance percentage or amount, match variance icons are displayed in the Vendor invoice form and in the Invoice matching details form.

For example, you enter a purchase order with one line item for 500 pencils at a price of 1.00 each. The purchase order is approved and submitted to the vendor. The vendor ships 500 pencils, and you enter a product receipt for 500 pencils at a price of 1.00 each. The inventory cost for the pencils is updated with this price.

An invoice arrives for 500 pencils at a price of 1.10 each. Your legal entity policy allows a 5 percent net unit price tolerance for this category of item. A price of 1.05 would be acceptable, but 1.10 is not. When you enter the invoice information, a price matching discrepancy is identified and you can save the invoice until the discrepancy is resolved.

A vendor price tolerance group defines the group of vendors for which such a “price tolerance” is applicable. In other words, it is a vendor group to which a specified price tolerance is applicable. In the vendor form, this field describes the “identifier” for the vendor group.

Happy learning.!