Microsoft® Business Solutions–Navision® 4.0 includes a new functionality, Intercompany Postings, within its Financial Management series. Intercompany Postings is designed for Microsoft Navision users who control more than one legal business entity and have set up multiple companies within Microsoft Navision to separate the accounting functions of each of these entities. This broad description applies to many Microsoft Navision user businesses, especially those operating in international markets or regions with widely disparate business cultures and regulatory environments.

Your organization may consist of several companies, but might not have the equivalent number of accounting and administrative teams. Intercompany Postings lets you simplify and streamline business processes and transactions between all of these entities. Intercompany Postings is a significant enhancement to earlier versions of Microsoft Navisions, which did not include this capability. Users of previous versions of the product needed to re-key all information manually for all companies and transactions. Not only was this inefficient, but doing so also had a high potential for errors.

Once you implement Intercompany Postings, doing business with your subsidiary and internal partner organization becomes as easy as engaging with your external vendors and customers. You enter inter-company transaction information only once in the appropriate documents. You can use the Microsoft Navision functionalities you are already familiar with, such as receivables and payables management. Mapping facilities for the chart of accounts and dimensions help ensure that information appears in the right places.

In summary, there are four main benefits to Intercompany Postings:

Increased productivity as a result of time saved and simplified transactions
Minimized error potential with one-time entry of information and system-wide, automated updates
Complete audit trail and full visibility into business activities and transaction histories
Efficient, cost-effective transactions with affiliate and subsidiary companies

Streamlining the Flow of Business Activities

Intercompany Postings lets you distribute General Journal entries, as well as sales and purchasing documents, to all of your satellite offices, sales offices, or subsidiary companies, from within the Microsoft Navision business environment. Savings of time and increased efficiencies result throughout the organization as you eliminate redundant data entry and the sending, receiving, printing, and archiving of the sales and purchasing documents on paper.

Users are in full control of all transaction documents. For example, they can reject a document sent to them and, in this way, reverse postings that were incorrect. Or, when making a purchase from a partner or subsidiary company, they can update the purchase order as long as the selling company has not shipped any goods.

When users enter a transaction, they do not need to specify the accounts for an individual set of books, but simply give the identification of the partner company. Intercompany Postings creates General Journal lines that result—as soon as they are posted—in the balancing of the books of both companies involved in a transaction. The user has a drop-down menu to assign an inter-company partner code to any customer or vendor. From that moment on, all orders and invoices generated pertaining to transactions with these companies will produce corresponding documents in the partner company, again producing a reconciliation of the accounts.

In the following sections, we take a closer look at the workings of Intercompany Postings.

Efficient Inter-Company Transactions

Intercompany Postings functionality focuses on supporting inter-company transactions with sales and purchasing documents, and with General Journal lines. Within this area, Intercompany Postings allows multiple Microsoft Navision databases or multiple Microsoft Navision applications, for example, in different countries, as well as multiple currencies, different charts of accounts, different dimensions, and different item numbering.

Intercompany Postings uses a number of entries and documents in inter-company transactions:

General Journal entries
Purchase and sales orders
Purchase and sales invoices
Credit memos
Return orders

When users set up Intercompany Postings, they create a list of inter-company partners, called IC Partners, and an inter-company chart of accounts. Following these steps, users can perform inter-company General Journal transactions. They set up dimensions—if needed—separately. Note that the General Journal by itself does not include currency functionality, but converts all amounts at the applicable rate to the local currency.

After the user sets up business partners as customers and vendors in the system, and assigns them inter-company partner codes, it is possible to exchange inter-company purchase and sales documents, including items and item charges. The receivables and payables functionalities in Microsoft Navision include the capability of handling different currencies; inter-company transactions can proceed in any required currency.

Creating a Complete Audit Trail

When you make full use of the capabilities of Intercompany Postings, individual transactions can become elements in a single, fully connected accounting process with a complete audit trail of business activities between your partner and subsidiary companies. Each company in the organization can start a transaction flow by posting a document. Intercompany Postings sends the corresponding partner documents to the partners for processing. Both the parent company and the subsidiaries can refer to the audit trail.

When you perform transactions using the Customer and Vendor functionalities, the audit trail includes several elements that can give you increased visibility and tracking of events:

Document numbers of inter-company purchase and sales orders and invoices
IC Partner code tagged onto each Intercompany Postings transaction
Entry number and source code—the more standard audit trail elements available outside of Intercompany Postings

With these auditing criteria, you can search and locate effortlessly any documents and information involved in a transaction, and can make your periodic reconciliation process easier.

Supporting Diverse Business Environments

With Intercompany Postings, Microsoft Navision can effectively accommodate a wide range of different business scenarios and company configurations. Intercompany Postings includes a mapping capability to increase the ease and efficiency of inter-company transactions by using different charts of accounts as well as dimensions.

Users can create charts of accounts for inter-company transactions, called IC Charts of Accounts, and a table for each dimension applied to such transactions, referred to as an IC Dimension. To begin with, users need to set up a “master” IC Chart of Accounts and a “master” table for each IC Dimension. The parent company arranges the IC Chart of Accounts and IC Dimension to be used for inter-company transactions. In turn, each subsidiary or partner company can map its local chart of accounts to the “master” IC Chart of Accounts, and map its local dimensions to each of the IC Dimensions.

As users incorporate separate Microsoft Navision databases into the inter-company business scenario, and make use of the flexible setup capability to create inter-company entities, Intercompany Postings can support inter-company transactions to suit widely disparate business requirements.

Architecture of the Intercompany Postings Module

There are three main elements in the architecture of Intercompany Postings:

Business Logic
Intercompany Inbox and Outbox
Transfer of Information Between Companies

Business Logic

Microsoft Business Solutions developers wanted to minimize the need for new functionality within Microsoft Navision and make it easier for users to learn and benefit from Intercompany Postings. For these reasons, they made small modifications to existing capabilities of Microsoft Navision to accommodate inter-company transactions. The business logic for inter-company transactions is not different from that of other transactions, and most users will be able familiarize themselves and work with the new module in a very short time.

Microsoft Navision now includes an Intercompany General Journal. Existing receivables and payables functionalities were enhanced to support inter-company transactions that incorporate documents. The customer and vendor cards now feature a new field called the ICPartner field which tells the user that a customer or partner is an inter-company entity. Intercompany Postings treats partner companies as regular customers and vendors, again eliminating a need for specialized or additional functionality. Partner companies, in the present context, can be any companies controlled by one legal entity: the parent company, subsidiaries, sister companies, and others.

When, as a result of a transaction or business process, users create documents that involve inter-company partners, there are two ways to make the relevant information available to the partner:

Sending the document without posting it, in the case of sales and purchase orders
Posting the document in the IC General Journal, for invoices, credit memos, return orders, and actual IC General Journals

Because the IC Partner field on the customer or vendor cards notifies the system that it is dealing with an inter-company partner, Microsoft Navision transfers the relevant information contained in a business document to a special repository called the IC Outbox. From there, it can be sent to the partner company.

Intercompany Postings includes Customer and Vendor features, which add to the flexibility available to the Microsoft Navision user. Each inter-company partner can be assigned to one customer and/or one vendor. Using these features makes it possible to process multiple currencies. Intercompany Postings can assign a different currency to each partner and, in this way, support international subsidiaries. The module can also accommodate companies using disparate databases and a different chart of accounts. For example, it can incorporate an additional, different value-added tax (VAT) schema.

Intercompany Postings Inbox and Outbox

Intercompany Postings uses an IC Inbox and IC Outbox to allow the creation of journal entries in a partner company with little effort and maintain a smooth workflow. The IC Inbox and IC Outbox support multiple databases, which are being implemented typically by companies whose parent organization and subsidiaries are internationally distributed. IC Inbox and IC Outbox give Microsoft Navision users full control over the document flow entering and exiting the company, and allow them to manage each transaction separately from all others.

IC Outbox. When users post an inter-company transaction, Intercompany Postings transfers the information for the partner to the IC Outbox. If the information is correct, it can be sent on to the partner for processing.

However, if the transaction is the result of an error, the user can cancel it and, thereby, stop the information from reaching the partner. If a user realizes that the IC Outbox contains an incorrect transaction, there are two ways to make the correction:

Reverse the transaction, if it was a General Journal transaction.
Post the reversal, for example, as a credit memo for an incorrect sales invoice, and cancel the original transaction document and the reversal when both of them are in the IC Outbox.

IC Inbox. Microsoft Navision users can review all incoming documents from partner companies in the IC Inbox. They can handle each transaction separately, or use filters to process several transactions simultaneously. If the user accepts an inter-company transaction, Intercompany Postings will create the corresponding documents or IC General Journal lines for the user’s company. At that point, the user will need to access the relevant Microsoft Navision application area to continue processing the information.

Users can reject incorrect inter-company transactions. If they do so, Intercompany Postings will return the transaction information to the partner or subsidiary that sent it originally. That partner then can review the information and take action, such as reversing the original transaction document and creating a new, correct document.

However, if the rejection itself was in error, a single action can undo it. As a result of the rejection, the transaction information moves to the IC Outbox. As long as it has not been sent to the partner, the user can cancel the rejection by using an option called Return to IC Inbox. This option reconstitutes the original inter-company transaction in the IC Inbox, where the user can accept it.

Figure 1 illustrates the movement of data in Microsoft Navision Intercompany Postings either within the same database, or between different databases.

Figure 1. Moving data within the same database, and between different databases.

Transfer of Information Between Companies

Intercompany Postings facilitates four different methods to transfer information between companies and their partners or subsidiaries. Users define the type of transfer to be used for each partner. These are the four transfer options:

File Location. This option writes transactions sent from the IC Outbox to files in XML, creating one file per partner. The XML files are saved in previously specified file locations, such as a client PC or a network resource.

Database. This option causes transactions to be written directly from one company’s IC Outbox to the recipient company’s IC Inbox.

E-Mail. This option, too, formats transactions as XML files. It does not save them, but sends them on immediately as e-mail attachments.

No Transfer. Users select this option in case they prefer alternative transmission formats. These may include printed invoices, manual data entry, or another type of electronic transfer, for example, through Microsoft BizTalk®.

Practical Application and Business Scenarios for Intercompany Postings

In the following paragraphs, we walk you through five likely business scenarios for Intercompany Postings users. These scenarios correspond to frequent business situations in which Microsoft Navision users find themselves. The high potential of Intercompany Postings to produce benefits in form of cost savings, efficiency, productivity, and auditing capability will become more practically evident as you review these generalized descriptions.

Invoicing an Intercompany Partner

This scenario is probably the most basic and, perhaps, also the most common for Intercompany Postings. It unfolds as follows:

An accounts receivable administrator working with Navision at one company creates an invoice for a partner company. The invoice lists items that make it only slightly different from an invoice that covers only service fees. Once the invoice has been shipped and posted, the sales invoice information moves to the IC Outbox, from where it can be sent to the partner company. The partner company, in turn, receives the information needed to create the corresponding purchase invoice. That task can be accomplished from the IC Inbox after the relevant information has been accepted. When the partner has registered that the items or services have been received, the purchase invoice can be posted. As data was entered once only, by the selling company, the two organizations’ books will balance.

Figure 2. Sales invoice document flow.

Sending Purchase Orders to a Central Warehouse

Imagine, as a parent company in this example, a small construction company. The company has several partners or subsidiaries, each of them representing one building project. The parent company purchases all raw materials for all jobs, and sells them to the partner companies through one main warehouse. In this way, the construction company can manage centrally all costs incurred through external vendors, and minimize the administrative workload associated with handling payments, such as payables management and check writing.

The construction company uses the Navision Intercompany Postings functionality to set up a list of partners, which Navision treats, from then on, just like it does other, external customers and vendors. For example, when a partner company needs to order building materials from the central warehouse, this partner sends a purchase order directed to the vendor account that represents the warehouse. The purchase order arrives at the warehouse in form of a sales order applying to the warehouse’s customer account for that partner.

When the sale is complete, Navision users post an invoice and send it from the warehouse to the partner company. At the partner company, Navision applies the invoice number to the original purchase order, which can then be posted. This step completes the transaction for both companies.

Figure 3. Sending purchase orders and posting invoices. (Note that shipping and receiving is not part of Intercompany Postings.)

Allocating Overhead Costs

Allocation of overhead costs is an extremely frequent business practice that almost always takes place when several companies are in the control of one legal entity. Overhead costs can represent a wide variety of items, including rent, facilities maintenance, janitorial services, or the cost of operating the company’s network. Overhead costs could also be generated by the use of consultants, lawyers, auditors, or other professional services. Frequently, companies and their subsidiaries share centralized services, for example, for payroll, human resources, or accounting, again making it necessary to allocate overhead costs appropriately.

The most straightforward way to allocate costs to partner or subsidiary companies is to use the Intercompany General Journal. The allocating company—usually the parent company—would post cost items to a specific account. When costs need to be posted to multiple accounts, the procedure needs to be repeated for each general ledger account. When allocating the cost using the IC General Journal, the cost is credited to the parent company’s expense account, with a corresponding debit in the receivables account for each subsidiary that is allocated a share of the cost.

Assume, for example, that the parent company—which keeps its books in British pounds or GBP—allocates a £14,000 management fee to two subsidiaries. One is allocated £9,000, the other £5,000. The IC General Journal entry posting this allocation will look like this:

The two subsidiaries will receive the following General Journal lines:

Subsidiary A:

Subsidiary B:

If the subsidiaries keep their books in a currency other than GBP, the payables amounts register upon posting at a converted rate in the subsidiaries. The payables accounts in the subsidiaries balance the receivables account in the parent company.

Figure 4. Allocating overhead costs.

Using Intercompany Postings and Advanced Dimensions to Centralize Purchasing

The following scenario is relevant when one company performs all or most of the purchasing from external vendors for subsidiaries and the parent company. For example, such centralized purchasing can take place when a warehouse takes care of all procurement for a number of sales offices, or when the company’s IT department centrally manages purchasing of equipment and services. What these arrangements have in common is that external vendors bill the central purchasing entity. That group will complete the transaction with the vendor and subsequently allocate the costs to the partner companies that actually consume the goods or services.

When subsidiaries purchase and consume discrete, specific items, it is easy to allocate costs. However, when they incur costs, such as those of services and utilities, that represent a continuous overhead, managers need to determine the correct proportions for allocating these costs to the subsidiaries. One way to allocate such “cost pools” could take place in the following manner:

The central purchasing organization sets up a dimension called IC Partner, with a dimension for each subsidiary. These dimensions can be assigned to costs incurred by specific partners. At the end of reporting periods, financial managers can use Navision Intercompany Postings to produce a report on the cost items allocated to any partner, and create a sales invoice with the amount to be balanced. The cost item report can be attached to this invoice as substantiation.

Figure 5. Centralized purchasing.

To make allocation of such overhead costs even easier, you could add an overhead dimension to the IC Partner dimension. Consider, however, that in many cases the actual allocation will depend on the kind of costs incurred. For example, rent might be allocated only to partner companies sharing the same premises as the parent company. IT costs might require a different allocation than the costs of accounting services. Therefore, allocating these costs would require a different dimension value for each type of allocation. Any costs that should be allocated in the same way to partner companies can be pooled by assigning them the same dimension value. At the end of each reporting period, each cost pool can be reported on and allocated to the partner companies to which it applies. Each partner or subsidiary will receive a sales invoice showing the amount that represents its proper share of overhead costs.

We should mention another good reason for not forwarding each invoice for a purchase to the subsidiary that was the recipient of the cost item. Reducing inter-company transactions to one or a few invoices at the end of the reporting period can simplify the reconciliation process. Only one company’s books plus a small number of inter-company transactions have to be reviewed if there is a balance discrepancy.

Figure 5 illustrates the “flow” of events if Intercompany Postings had not been used to centralize and simplify purchasing, and every vendor had to invoice every partner—a significantly more complicated operation.

Figure 6. Operations without centralized purchasing.

Using the General Journal to Post Interim Sales Figures

When subsidiary companies engage in sales efforts, scenarios similar to the ones just discussed can take place. The scenario we are about to discuss minimizes and simplifies the flow of documents, reduces the need for manual data entry, and helps parent and subsidiary companies have a dependable representation of a reporting period’s sales results.

If a sales office takes the parent company’s products to market and owes the parent company royalties or other fees, the number of transactions can be high enough to cause a substantial amount of administrative effort, which, in turn, could erode the margins. Implementing Navision Intercompany Postings will remove a portion of this workload by reducing the number of times information must be entered. Additionally, posting interim General Journal lines will reduce the number of documents that need to be posted.

If the sales office registers each sale as an IC General Journal posting, the sales office can always perform the following without having to wait for a period-end invoice from the parent company:

Credit the parent company
Debit the expense account representing royalty fees
Report the contribution margin

At the end of reporting periods, the parent company will receive documentation for the sales resulting in royalty payments, post a sales invoice, and also post a reversal of the interim entries.

Figure 7. Posting interim sales figures.

Recommendations and Best Practices

Several recommended practices can make your implementation of Intercompany Postings even more easy to use and even more efficient.

Identifying Partners and Vendors

As mentioned, the Intercompany Postings business logic allows you to assign each inter-company partner to one customer and/or vendor. You can make it easier to identify inter-company partners in the customer or vendor lists. Simply use customer and vendor numbers that are the same or similar to the inter-company reference or IC Code assigned to the respective partner company.

Selecting Transfer Methods

We described the four methods Intercompany Postings offers for transferring transaction information from one company to another. Depending on which Microsoft Navision database companies and their data reside in, and depending on whether these databases are on the same network or not, we recommend different selections and configurations of transfer options. Remember that the data transfer for companies in different databases proceeds by means of XML files that either are saved in a designated network folder or mailed to a specified e-mail account by using the sender’s e-mail client.

Companies residing in the same database: Select Database as the transfer option for the IC Inboxes of these inter-company partners. Be sure to specify the company names in the IC Inbox details.
Companies residing in different databases on the same network. Specify inter-company partners’ IC Inbox type as File Location. The IC Inbox details need to list a network folder that the partners can assess.
Companies residing in different databases on different networks. Set the IC Inbox type for these inter-company partners as either FileLocation or E-Mail. The IC Inbox details need to include either a folder location or an e-mail address. If you use the FileLocation option, users will need to find to find a way to transfer the files to the partner companies, for example, on a compact disc or floppy disk, via e-mail, or network resources.

Purchase Invoices and Purchase Credit Memos

You can create purchase invoices and purchase credit memos from the information you receive in sales invoices or credit memos created by partner companies. You will not be able to start a document flow with a purchase invoice or a purchase credit memo because these two documents need information from the corresponding sales documents.

Items

There are certain restrictions applying to the items that can occur in inter-company transactions. Not all item information can be transferred between companies. Variant codes, unit of measure, and location, for example, cannot be transferred. You need to add manually the location information to any document lines that require it. Intercompany Postings will let you transfer item charges as long as they are identical in both companies involved. If item charges are not identical, you need to choose a local item charge code.

You can use several different methods for mapping item numbers between companies: When item numbers are the same, if Common number from the e-commerce tab on the Item Card is to be used, or if the Vendor Item Catalog is to be used to map item numbers, Intercompany Postings assumes that variant codes and units of measure are the same for the item in both companies. If you need variant codes, use the Cross-Reference functionality.

Updating Information

Intercompany Postings gives you the possibility of modifying information in transaction documents, so you can structure the transaction workflow to be most effective for your business environment. This means that, when you work with sales or purchase documents, you should be aware of the workflow in order to ensure a balanced set of books in all interacting companies.

Intercompany Postings will let you update and resend a purchase order to the partner company as long as no goods have been received. However, the books in both companies will balance only if the selling company accepts the latest purchase order.

When you receive information in a sales invoice—which is, effectively, the information you need to post an open purchase order—Intercompany Postings will display a warning message if the received invoice amount does not match the order amount. In that case, you need to either reject the received invoice information, or update the order before posting.

Setup

To begin setting up Intercompany Postings and perform inter-company transactions, each company will need three things:

A list of partner companies and information about these partners. This list will need to include each company’s unique Intercompany Postings code, the name of any partner companies, and information about the IC Inbox of each partner, so that inter-company transaction information can be sent to those partners.
Agreement to a common chart of accounts
Understanding of commonly used dimensions

The above is all that is needed if only General Journal entries are to be used in inter-company transactions. With this arrangement, a user can enter a General Journal line, and specify that the account type is IC Partner for one side of the entry. When users post to an IC General Journal, the journal lines pertaining to the partner company will be sent to the partner through the IC Outbox. When the partner accepts those lines, they will be created as IC General Journal lines in the partner company and can be posted.

Moving Toward Implementation

As a Microsoft Navision user engaged in doing business with a growing number of customers, and involved with a complex network of vendors and business partners, you can derive tangible cost, productivity, and efficiency benefits from Intercompany Postings. As you change a collection of islands of business data into an encompassing, transparent flow of business activities between the parent company and the subsidiaries and partners under its control, you can improve the dependability and productivity of your internal processes, and serve your diverse customer communities more effectively.

Implementation of Microsoft Navision and the Intercompany Postings module incorporates the business and technical expertise of Microsoft Business Solutions partners, who can assist you in designing an optimal business environment that reflects your specific requirements and preferences. To connect with the Microsoft Business Solutions partner closest to you, go to http://www.microsoft.com/BusinessSolutions/.

System Requirements

Intercompany Postings is a component of Microsoft Business Solutions–Navision version 4.0. Users need to implement Microsoft Navision 4.0 with Intercompany Postings and Basic General Ledger. To use the Receivables and Payables feature, you need to acquire the granule for each type of functionality before you can work with Intercompany Postings. To send mail to an inter-company partner, you need an e-mail client.

Intercompany Postings does not include any special security features. The security level applicable to the sending of XML files depends on the security level of the corporate network and of the mail client. Most often, a mail client would allow users to encrypt data sent through e-mail messages.