Custom ERP Development: When to Build vs Buy, Architecture & Real Costs

By Viprasol Tech Team

---

The decision to build a custom ERP instead of buying SAP, Oracle, Microsoft Dynamics, or NetSuite is a decision most companies should not make. Commercial ERP systems exist because the core business functions they handle — general ledger, accounts payable, accounts receivable, inventory, procurement, HR — are well-understood, largely standard, and expensive to build correctly.

That said, there are specific scenarios where building a custom system — or custom modules that integrate with an existing ERP — is genuinely the right choice. This guide covers when custom ERP development makes sense, what the architecture looks like, and what it costs.

---

When Custom ERP Development Is the Right Choice

The threshold question: is your business process genuinely differentiated, or just unfamiliar?

Most business processes that feel unique are actually standard. Procurement workflows, invoice approval chains, inventory valuation methods, payroll calculations — these have been codified in commercial ERPs across thousands of implementations. Your specific approval limits and GL codes are configuration, not customization.

Build custom when:

• Your core business process is genuinely proprietary and provides competitive advantage
• Commercial ERP implementation costs exceed custom development costs over a 5-year horizon
• The commercial ERP requires so much customization that you're effectively building custom software inside a rigid platform
• You need deep integration with proprietary equipment, specialized data sources, or industry-specific systems that commercial ERPs don't support
• You're in an industry with unusual regulatory requirements that commercial ERPs handle poorly (certain types of financial trading, specialized manufacturing)

Never build custom for:

• Standard financial accounting (general ledger, AP/AR, bank reconciliation)
• Payroll (regulatory complexity across jurisdictions makes this a nightmare to build)
• HR/benefits administration (use Workday, ADP, or BambooHR)
• Standard procurement workflows (NetSuite or Dynamics handles this)

The hybrid approach — commercial ERP for standard functions, custom development for differentiating workflows, with integration middleware connecting them — is the correct architecture for most companies that think they need a custom ERP.

---

ERP Architecture: Core Components

If custom ERP development is the right choice for your use case, these are the architectural building blocks:

1. Double-Entry Accounting Engine

The general ledger is the foundation of any ERP. Every financial transaction generates two balanced journal entries:

// Chart of accounts and double-entry transaction recording
interface Account {
  id:       string;
  code:     string;   // e.g., "1000" = Cash, "2000" = AP, "4000" = Revenue
  name:     string;
  type:     'asset' | 'liability' | 'equity' | 'revenue' | 'expense';
  currency: string;
}

interface JournalEntry {
  id:          string;
  date:        Date;
  description: string;
  reference:   string;        // invoice number, PO number, etc.
  lines:       JournalLine[]; // must balance: sum(debits) === sum(credits)
  postedBy:    string;
  status:      'draft' | 'posted' | 'reversed';
}

interface JournalLine {
  accountId:    string;
  debitAmount:  number;  // exactly one of debit/credit is > 0
  creditAmount: number;
  description:  string;
}

// Database constraint: journal entries must balance
// Enforced at application level AND via PostgreSQL trigger
async function postJournalEntry(entry: Omit<JournalEntry, 'id' | 'status'>) {
  const totalDebits  = entry.lines.reduce((sum, l) => sum + l.debitAmount,  0);
  const totalCredits = entry.lines.reduce((sum, l) => sum + l.creditAmount, 0);

  if (Math.abs(totalDebits - totalCredits) > 0.001) {  // floating point tolerance
    throw new Error(`Journal entry does not balance: debits ${totalDebits} ≠ credits ${totalCredits}`);
  }

  return await db.$transaction(async (tx) => {
    const je = await tx.journalEntry.create({ data: { ...entry, status: 'posted' } });
    await tx.journalLine.createMany({ data: entry.lines.map(l => ({ ...l, journalEntryId: je.id })) });
    return je;
  });
}

2. Inventory Management

Inventory valuation method (FIFO, LIFO, weighted average) affects the cost of goods sold calculation. FIFO is the most common and the simplest to implement:

// FIFO inventory: oldest stock is sold first
async function recordInventoryReceipt(params: {
  productId: string;
  quantity:  number;
  unitCost:  number;
  supplierId: string;
  poNumber:  string;
}) {
  await db.$transaction(async (tx) => {
    // Create inventory lot (FIFO tracking)
    const lot = await tx.inventoryLot.create({ data: {
      productId:    params.productId,
      quantityOnHand: params.quantity,
      unitCost:       params.unitCost,
      receivedAt:     new Date(),
      poNumber:       params.poNumber,
    }});

    // Update product summary
    await tx.product.update({
      where: { id: params.productId },
      data:  { quantityOnHand: { increment: params.quantity } }
    });

    // GL entry: debit Inventory, credit Accounts Payable
    await postJournalEntry({
      date:        new Date(),
      description: `Inventory receipt — PO ${params.poNumber}`,
      reference:   params.poNumber,
      postedBy:    'system',
      lines: [
        { accountId: INVENTORY_ACCOUNT, debitAmount: params.quantity * params.unitCost, creditAmount: 0, description: 'Inventory' },
        { accountId: AP_ACCOUNT,         debitAmount: 0, creditAmount: params.quantity * params.unitCost, description: 'AP' },
      ],
    });
  });
}

3. Procurement Workflow Engine

Purchase orders flow through approval chains before being issued to suppliers. Approval rules are configurable by amount, department, or category:

type ApprovalStatus = 'pending' | 'approved' | 'rejected' | 'cancelled';

interface ApprovalRule {
  minAmount:   number;
  maxAmount:   number;
  approverRole: string;
  slaHours:    number;  // auto-escalate if not actioned within this window
}

const APPROVAL_RULES: ApprovalRule[] = [
  { minAmount: 0,       maxAmount: 1000,  approverRole: 'department_manager', slaHours: 24  },
  { minAmount: 1000,    maxAmount: 10000, approverRole: 'finance_manager',    slaHours: 48  },
  { minAmount: 10000,   maxAmount: Infinity, approverRole: 'cfo',             slaHours: 72  },
];

function getRequiredApprovers(amount: number): ApprovalRule[] {
  // All rules that apply to this amount must approve
  return APPROVAL_RULES.filter(r => amount >= r.minAmount);
}

4. Reporting Engine

Financial reports — Profit & Loss, Balance Sheet, Cash Flow Statement — are derived from the general ledger. The key design decision: precompute account balances periodically, or compute them on-demand from journal entries.

For most ERP scales (up to millions of transactions), on-demand computation with materialized views is the right approach:

-- Materialized view: account balances by period
CREATE MATERIALIZED VIEW account_balances AS
SELECT
  a.id           AS account_id,
  a.code,
  a.name,
  a.type,
  DATE_TRUNC('month', je.date) AS period,
  SUM(jl.debit_amount)  AS total_debits,
  SUM(jl.credit_amount) AS total_credits,
  -- Normal balance by account type
  CASE WHEN a.type IN ('asset', 'expense')
    THEN SUM(jl.debit_amount) - SUM(jl.credit_amount)
    ELSE SUM(jl.credit_amount) - SUM(jl.debit_amount)
  END AS balance
FROM accounts a
JOIN journal_lines jl  ON jl.account_id = a.id
JOIN journal_entries je ON je.id = jl.journal_entry_id
WHERE je.status = 'posted'
GROUP BY a.id, a.code, a.name, a.type, DATE_TRUNC('month', je.date);

-- Refresh nightly
CREATE UNIQUE INDEX ON account_balances (account_id, period);

---

Integration Middleware Pattern

For the hybrid approach (commercial ERP + custom modules), a middleware layer handles data synchronization:

Custom Application
    ↓ REST API call
Integration Middleware (Node.js + BullMQ queue)
    ↓ retry with exponential backoff
Commercial ERP API (SAP BAPI, Oracle REST, Dynamics OData)

The middleware must handle:

• Retry logic — ERP APIs have rate limits and occasional failures
• Idempotency — if the sync job runs twice, no duplicate records
• Error alerting — failed sync operations need human attention, not silent failure
• Data mapping — field-by-field transformation between your schema and the ERP schema

---

Custom ERP Development Cost Ranges

For comparison: SAP S/4HANA implementation for a mid-size company costs $500K–$5M+ in licensing and consulting — often more than custom development. The build vs. buy math sometimes does favor custom.

---

Working With Viprasol

Our enterprise software development practice builds custom ERP modules, ERP integration middleware, and industry-specific business management systems. We understand double-entry accounting, procurement workflow design, and the integration patterns for SAP, Oracle, and Dynamics.

We are not the right choice to replace your existing SAP instance. We are the right choice when SAP's customization limits what you need to do, or when you're building an industry-specific system from scratch.

Building a custom ERP or ERP module? Viprasol Tech develops enterprise business software for startups and growing companies. Contact us.

---

See also: Enterprise Software Development · Digital Transformation · Custom Software Development Cost

Sources: SAP Business Technology Platform · Microsoft Dynamics 365 Docs · Gartner ERP Magic Quadrant 2025