Cost / Revenue Center to CoA Map

Excellent request. This is a crucial step in making the Chart of Accounts (CoA) truly functional for management reporting. The mapping table connects the operational structure of the business (Cost and Revenue Centers) to the financial structure (the CoA). Here is a design for a mapping table, complete with examples and principles.

​

General Concept

​

I. Defining the Cost and Revenue Centers

First, let’s establish a set of hypothetical Cost and Revenue Centers for our enterprise. The codes are essential for system integration (e.g., in an ERP system). Revenue Centers (RC):

• RC-101: Product Sales - SaaS Platform
• RC-102: Product Sales - Hardware Devices
• RC-201: Professional Services - Implementation
• RC-202: Professional Services - Training

Cost Centers (CC):

• CC-100: General & Administrative (G&A)
• CC-200: Sales Department
• CC-300: Marketing Department
• CC-400: Research & Development (R&D)
• CC-500: Customer Support
• CC-600: Operations / Production

​

II. How the Mapping Works in Practice

In a modern accounting system, you don’t create separate CoA accounts like “Marketing Salaries” and “R&D Salaries.” Instead, you use a single account, for example, 71100 - Salaries & Wages, and then “tag” the transaction with the appropriate Cost Center dimension (e.g., CC-400 for R&D). The mapping table below illustrates which types of transactions are booked against which Cost/Revenue Centers and how they affect the CoA.

• Revenue transactions are mapped to Revenue Centers.
• Expense transactions are mapped to Cost Centers.
• Balance Sheet transactions (e.g., paying a supplier, moving cash) typically are not mapped to a specific center, as they reflect the company’s overall financial position. The expense or revenue part of the transaction is what gets mapped.

​

III. Mapping Table: Business Activity to CoA Entries

This table demonstrates common business activities and shows how the journal entries would be coded with the appropriate center and CoA accounts.

​

IV. Key Principles of the Mapping Logic

1. Tag the P&L, Not the Balance Sheet: The primary goal is to analyze profitability and control spending. Therefore, you tag Revenue (4xxxx) and Expense (5xxxx-8xxxx) accounts. Balance Sheet accounts (1xxxx, 2xxxx, 3xxxx) are generally not tagged because they represent the company’s overall financial state, not a departmental activity.

• Exception: Sometimes, fixed assets (like a specific machine for R&D) might be tagged to a cost center for tracking purposes, but the associated depreciation expense is what truly matters for P&L reporting.

2. Debit for Expenses, Credit for Revenue:

• When an expense is incurred, the expense account in the CoA is Debited and tagged with the relevant Cost Center.
• When revenue is earned, the revenue account in the CoA is Credited and tagged with the relevant Revenue Center.

3. One-to-Many Relationships:

• A single Cost Center (like G&A) will map to many different expense accounts (e.g., Executive Salaries, Rent, Office Supplies, Legal Fees).
• A single expense account (like Salaries & Wages) will be used by many different Cost Centers (Sales, Marketing, R&D, G&A). This is the power of dimensional accounting.

This mapping structure allows the finance team to generate powerful reports, such as:

• A Profit & Loss statement for the “SaaS Platform” Revenue Center.
• A detailed budget vs. actual spending report for the “Marketing Department” Cost Center.
• An analysis of which cost centers are driving the most travel expenses.

​

Bahasa Indonesia

Tabel pemetaan ini menghubungkan struktur operasional bisnis (Pusat Biaya dan Pendapatan) dengan struktur keuangan (CoA). Berikut adalah desain untuk tabel pemetaan, lengkap dengan contoh dan prinsip-prinsipnya.

​

I. Mendefinisikan Pusat Biaya dan Pusat Pendapatan

Pertama, mari kita tentukan serangkaian Pusat Biaya (Cost Center) dan Pusat Pendapatan (Revenue Center) hipotetis untuk perusahaan kita. Kode ini penting untuk integrasi sistem (misalnya, dalam sistem ERP). Pusat Pendapatan (Revenue Centers - RC):

• RC-101: Penjualan Produk - Platform SaaS
• RC-102: Penjualan Produk - Perangkat Keras
• RC-201: Jasa Profesional - Implementasi
• RC-202: Jasa Profesional - Pelatihan

Pusat Biaya (Cost Centers - CC):

• CC-100: Umum & Administrasi (G&A)
• CC-200: Departemen Penjualan
• CC-300: Departemen Pemasaran
• CC-400: Penelitian & Pengembangan (Litbang)
• CC-500: Dukungan Pelanggan
• CC-600: Operasional / Produksi

​

II. Cara Kerja Pemetaan dalam Praktik

Dalam sistem akuntansi modern, Anda tidak membuat akun CoA terpisah seperti “Gaji Pemasaran” dan “Gaji Litbang”. Sebaliknya, Anda menggunakan satu akun tunggal, misalnya 71100 - Gaji & Upah, lalu “menandai” (tagging) transaksi tersebut dengan dimensi Pusat Biaya yang sesuai (misalnya, CC-400 untuk Litbang). Tabel pemetaan di bawah ini menggambarkan jenis transaksi mana yang dibukukan ke Pusat Biaya/Pendapatan mana dan bagaimana pengaruhnya terhadap CoA.

• Transaksi pendapatan dipetakan ke Pusat Pendapatan.
• Transaksi beban dipetakan ke Pusat Biaya.
• Transaksi Neraca (misalnya, membayar pemasok, memindahkan kas) biasanya tidak dipetakan ke pusat tertentu, karena mencerminkan posisi keuangan perusahaan secara keseluruhan. Bagian beban atau pendapatan dari transaksilah yang dipetakan.

​

III. Tabel Pemetaan: Aktivitas Bisnis ke Entri CoA

Tabel ini menunjukkan aktivitas bisnis yang umum dan bagaimana entri jurnal akan dikodekan dengan pusat dan akun CoA yang sesuai. (T/A = Tidak Ada / Tidak Berlaku)

​

IV. Prinsip Utama Logika Pemetaan

1. Tandai Laba Rugi, Bukan Neraca: Tujuan utamanya adalah untuk menganalisis profitabilitas dan mengendalikan pengeluaran. Oleh karena itu, Anda menandai akun Pendapatan (4xxxx) dan Beban (5xxxx-8xxxx). Akun Neraca (1xxxx, 2xxxx, 3xxxx) umumnya не ditandai karena mereka mewakili keadaan keuangan perusahaan secara keseluruhan, bukan aktivitas departemental.

• Pengecualian: Terkadang, aset tetap (seperti mesin khusus untuk Litbang) mungkin ditandai ke pusat biaya untuk tujuan pelacakan, tetapi beban penyusutan terkaitlah yang benar-benar penting untuk pelaporan Laba Rugi.

2. Debet untuk Beban, Kredit untuk Pendapatan:

• Saat beban terjadi, akun beban di CoA di-Debet dan ditandai dengan Pusat Biaya yang relevan.
• Saat pendapatan diperoleh, akun pendapatan di CoA di-Kredit dan ditandai dengan Pusat Pendapatan yang relevan.

3. Hubungan Satu-ke-Banyak (One-to-Many):

• Satu Pusat Biaya (seperti G&A) akan dipetakan ke banyak akun beban yang berbeda (misalnya, Gaji Eksekutif, Sewa, Perlengkapan Kantor, Biaya Hukum).
• Satu akun beban (seperti Gaji & Upah) akan digunakan oleh banyak Pusat Biaya yang berbeda (Penjualan, Pemasaran, Litbang, G&A). Inilah kekuatan akuntansi dimensional.

Struktur pemetaan ini memungkinkan tim keuangan untuk menghasilkan laporan yang kuat, seperti:

• Laporan Laba Rugi untuk Pusat Pendapatan “Platform SaaS”.
• Laporan perbandingan anggaran vs. realisasi pengeluaran yang terperinci untuk Pusat Biaya “Departemen Pemasaran”.
• Analisis pusat biaya mana yang paling banyak mengeluarkan biaya perjalanan dinas.

​

WCP as example

​

Storyline & Narrative

WCP is a company structured by departments & business unit like this :

• MPS, Man Power Services , this is SBU that generates revenue from Manpower outsourcing, activities will be grouped by project
• EPCIC , SBU that generates revenue from equipment rental plus manpower as operator, activities will be grouped by project
• BD, Business Development, unit responsible for finding leads, tender & bid participation and winning process, up to awarded contract for MPS, EPCIC and SCM ( non human resource procurements ) projects
• SCM , SBU as well as supporting unit , mainly dealing with vendor relation, procurement and fulfilment
• HCGA ( Human Capital & General Affairs ), supporting unit for GA & HR activities, including EPCIC HR management
• FAT, Finance and Accounting department

design possible table structure for RC / CC to CoA mapping

---

Of course. This is an excellent real-world scenario that highlights the need for a robust and dimensional accounting structure. Given your company’s structure with SBUs and support units, the design must clearly distinguish between direct costs (for profitability analysis) and overhead costs. Here is a design for the table structure, mapping your specific departments and SBUs to the Chart of Accounts (CoA).

​

Step 1: Finalize the Cost Center (CC) and Revenue Center (RC) Codes

First, we’ll assign clear, logical codes to each unit. This is the foundation of the system. Note that SCM has a dual role, so we can handle it with one code but use it in different contexts, or assign two for ultimate clarity. Let’s assign two to be explicit. Important Addition: The Project Dimension Your business is project-driven. The Project Code (e.g., PROJ-24-001) is a separate, mandatory dimension for all transactions related to RC-MPS and RC-EPCIC.

​

Step 2: Design the Core Mapping Table Structure

Here is a possible table structure. This isn’t just a static list; it’s a guide for how to code transactions in your ERP or accounting software.

​

Key Principles and Benefits of This Structure

1. Clear Profitability Analysis: By mapping all revenues and direct costs (COGS) to the SBUs (RC-MPS, RC-EPCIC), you can instantly generate a Gross Profit report for each SBU and even for each project.

• SBU Gross Profit = (All Credits to 4xxxx tagged RC-XXX) - (All Debits to 5xxxx tagged RC-XXX)

2. Overhead Cost Control: All indirect and overhead costs are neatly captured in the supporting Cost Centers (CC-BD, CC-HCGA, etc.). You can run budget vs. actual reports for each support department to manage spending effectively.
3. Flexibility for Allocation: While support costs are initially captured in their own CCs, this structure allows for a secondary step: cost allocation. At the end of the month, you could allocate the total costs of CC-BD to RC-MPS and RC-EPCIC based on a fair metric (e.g., percentage of revenue won), giving you a fully-loaded SBU Net Profit figure.
4. Handles Dual Roles: The structure explicitly separates SCM’s revenue-generating activities from its internal support function, preventing cost distortion and providing a clear view of its performance as both an SBU and a support unit.

This design provides the granularity needed for project-based accounting while maintaining a clear, high-level view of SBU performance and overall corporate overhead.