Why the ERPNext chart of accounts setup decides every later report
The chart of accounts, fiscal years, cost centers, taxes and opening balances must be settled before transactions post in ERPNext, because each one becomes a reference point that later documents inherit. Picture a finance team setting up a new company: they enter the first sales invoices and purchase bills quickly, then discover that the account tree, the year boundaries or the tax accounts were chosen in a hurry. (Illustrative.) Every balance sheet, profit and loss statement and tax report built afterward reads from those choices. Treat the setup as the first deliverable of the accounting project, with its own review and sign-off before any go-live testing begins.
The chart of accounts is the hardest part to change later. Once ledger entries exist against an account, restructuring the tree, moving balances between parent groups or changing an account's type can disturb the reports that depend on that structure. Account types, root types and the flags on each account, such as whether it accepts direct postings or requires a cost center, control how ERPNext classifies money in the statements. Confirm the exact account types and their behavior against the ERPNext documentation for your version before drafting the tree, and have an accountant review the proposed structure against the statutory reports the company must produce.
Multi-company and multi-currency choices reach further than the first company's ledger. Each company carries its own chart, default accounts, fiscal year and currency settings, and intercompany transactions depend on how those companies relate to each other. Currency decisions determine which currency each company books in, how exchange gains and losses are recorded, and how party accounts in other currencies are valued at period end. Ask the implementation team to document the reporting currency, the functional currency for each entity and the intercompany accounts before any master data is created, and to confirm how the chosen ERPNext version handles currency revaluation for open items.
Period closing depends on everything set up earlier. Fiscal years define the boundaries that closing entries and year-end reports use, cost centers and tax templates need to be stable before they appear on invoices, and opening balances must reconcile to the prior-year figures the new system starts from. If any of these change midway, closed periods may no longer agree with open ones. Plan a test close on a copy of the data, check that the trial balance, receivables and payables ledgers and tax totals reconcile, and keep a written record of who approved each setting so later changes can be traced.
Which ERPNext accounting components you configure
ERPNext accounting rests on a small set of linked settings, and several of them lock once transactions post. Review the components below in order, because the company, chart of accounts and fiscal years shape every later choice about taxes, cost centers, currencies and opening balances.
Company and default accounts
The Company record is the top-level legal entity that owns a chart of accounts, currency, default receivable and payable accounts, and default cost center. Each company in a multi-company setup needs its own record, and the defaults set here flow into invoices and payments. Confirm the legal name, base currency, tax identifiers and default accounts with your finance team before any transaction is posted.
Chart of accounts and account types
The chart of accounts is the hierarchy of ledger and group accounts that holds every posted amount. Each account carries an account type, such as Bank, Receivable, Payable, Stock or Tax, which tells ERPNext how to behave in reports and automated postings. Review the tree with your accountants against your statutory reporting lines, because renaming or restructuring accounts after posting is far more disruptive than getting the structure right at the start.
Fiscal year and period settings
The fiscal year defines the start and end dates that bound every period in the books. Overlapping or missing fiscal years cause posting errors and broken period reports, so confirm the year boundaries with your auditors and statutory calendar before creating them. Once transactions exist in a year, changing its dates requires care, so treat this as a decision to lock early.
Cost centers and their hierarchy
Cost centers classify income and expenses for management reporting, separately from the legal chart of accounts. Each company needs a root cost center, and the hierarchy should match how managers review performance, such as departments, branches or projects. Agree the structure with budget owners first, since splitting or merging cost centers later changes historical reporting and needs a reconciliation.
Tax templates and account-level tax
Sales and purchase tax templates map tax rates to specific tax accounts, and each rate posts to a ledger account in the chart. The tax accounts and the template structure determine how invoices, credit notes and returns report tax to the authority. Confirm the rates, rounding rules, tax exemptions and reporting requirements with your tax adviser, and test one invoice of each type before go-live.
Currency, exchange and multi-currency settings
Each company has a base currency, and foreign currency transactions need exchange rate sources and gain or loss accounts. Set the base currency before posting, because changing it after transactions exist is not a routine correction. Confirm which exchange rate source your finance team trusts and where unrealized and realized gains and losses should post, and document the revaluation routine.
Opening invoices and journal entries
Opening balances bring receivables, payables, bank balances and stock values into ERPNext at the go-live date, usually through opening invoices or journal entries against an Temporary Opening account. The totals must reconcile to the closing trial balance of the previous system, and the posting date should fall inside the first fiscal year. Plan the batch size and verification steps with the migration team before loading any data.
Period closing voucher
The Period Closing Voucher transfers the net profit or loss of a fiscal year into the balance sheet, typically to a retained earnings account, so the new year starts with correct opening balances. Run it only after the year's postings, adjustments and reconciliations are final, because later changes to that period require reversing and reposting. Confirm the closing account, approval steps and the sequence with your accountants before the first year-end.
Decisions to settle before the chart of accounts is built
This table compares the six setup decisions that shape the ERPNext chart of accounts, with the conditions under which each option fits and the ongoing cost of living with it. Read each row as a choice to make with finance and the implementation team before anyone creates accounts, because most of these are hard to reverse once transactions are posted.
| Decision | When the option fits | Operational cost of the option |
|---|---|---|
| Standard chart versus client ledger | Standard chart fits a new company or one with a simple structure; a client ledger fits organizations with reporting lines their auditors and lenders already rely on | Standard chart needs renaming and pruning of unused accounts; a migrated ledger needs account mapping, cleansing and a reconciliation to the legacy trial balance |
| One company versus several companies on one site | One company fits a single legal entity with one set of books; several companies fit group structures that need separate ledgers but shared masters | Each company adds its own chart, fiscal year and tax setup to maintain; intercompany transactions need a documented process and account owner |
| Single currency versus multi-currency | Single currency fits entities that book only in their functional currency; multi-currency with account currency fits accounts held or invoiced in foreign currencies | Revaluation and exchange gain or loss entries must run at each period close; confirm the exact configuration steps with your ERPNext version's documentation |
| Flat versus hierarchical cost centers | Flat cost centers fit small reporting needs; a hierarchy fits budgets and reports that roll up by department, region or project | Hierarchies need an owner to approve new branches; uncontrolled growth makes budget comparisons and reports harder to read over time |
| Taxes attached per item versus per account | Item tax templates fit businesses where tax rates differ by product; account-level tax fits businesses where rates depend mainly on the transaction type or customer | Item templates need upkeep whenever a product is added or a rate changes; account-level setup concentrates changes but may need review for exempt items |
| Opening balances through opening documents versus Data Import | Opening invoices and journal entries fit small balance sets with few open items; the Data Import tool fits larger volumes, with batches kept to a few thousand records | Opening documents take manual entry time; Data Import needs clean templates, test runs and a reconciliation to the legacy trial balance before go-live |
Build order for ERPNext accounting, step by step
This sequence takes an ERPNext accounting setup from confirmed legal structure to a tested, reconciled and repeatable close. Each step ends with an artifact that the finance lead and the implementation team can check before the next step begins.
Confirm entities, currencies and fiscal calendar
The finance lead and the implementation team list every legal entity in scope, its functional currency, its statutory year-end, its tax registration and any reporting currency the group needs. A signed decision sheet becomes the input for every later step. It is done when each entity on the sheet matches the company register extract and tax registration records, and when the open questions are assigned to a named owner with a due date agreed in writing.
Create the company records
An ERPNext administrator creates one Company record per legal entity, setting the default currency, the company abbreviation and the default accounts that ERPNext generates on creation. The abbreviation prefixes account names across the system, so it must be unique and agreed before any account is created. The step closes when the company list shows each entity once, the abbreviations are unique, and the generated default accounts have been reviewed against the decision sheet.
Shape the chart of accounts from the approved design
The accounting lead loads the approved account tree, either by editing the standard template or by importing the design from a spreadsheet with the Chart of Accounts Importer. Root types, account types and frozen accounts are set so that financial statements and tax reports classify balances correctly. The step closes when an exported account tree is compared line by line with the approved design, with no unmatched accounts and every leaf account carrying a root type and account type that the reports depend on.
Set fiscal years and cost centers
The administrator creates fiscal years that match each entity's statutory calendar, then builds the cost center tree from the reporting design agreed with the controller. Cost centers should map to the way managers are held accountable, not to the org chart by default. The step closes when a test Profit and Loss report for the first fiscal year runs without errors, and cost center totals roll up correctly to their parent centers.
Configure and test tax templates
The tax specialist builds item tax templates and sales and purchase tax templates for each jurisdiction, then posts sample invoices covering every standard rate, exemption and zero-rated case in the test script. Templates are tested on documents, not just reviewed on screen. The step closes when the tax report for the sample invoices matches the figures calculated by hand in the signed test script, and the tax liability accounts balance to the sample totals. Confirm the reporting format with the tax authority rules that apply to your entity.
Set multi-currency and exchange settings if needed
This step applies only to entities that transact in a foreign currency. The administrator enables multi-currency accounts, sets the exchange rate source the finance team will use, and defines the accounts for realized and unrealized exchange differences. The step closes when a test invoice and payment in a foreign currency are posted, a revaluation is run, and the resulting gain or loss posts to the designated account in the amount calculated independently in a spreadsheet.
Load opening balances and reconcile them
The accountant loads opening balances from the prior ledger as a balanced opening journal entry for each company, and loads open receivables and payables through the Data Import tool in small batches rather than as one large file. The source system's final trial balance is the reference. The step closes when the ERPNext trial balance at the cutover date matches the source trial balance account by account, and receivable and payable ageing totals agree with the open item lists signed off by the business.
Test two periods and rehearse the close
The finance team posts test transactions across two consecutive periods, including accruals, reversals, payments, intercompany entries and any foreign currency items. It then runs the period closing procedure on a staging copy and writes each step into a closing checklist with a named owner. The step closes when the rehearsed close produces the same balance sheet and profit figures as the test script, and the checklist has been signed off by the controller as the procedure the team will use live.
What drives accounting setup effort and how to keep it down
This table lists the drivers that change how much work an ERPNext accounting setup takes, why each one matters, and one practical way to reduce it. Read it before fixing project scope, because most drivers are settled during chart design and data preparation, well before go-live. The main takeaway is that agreeing the entity count, opening balance scope and report list in writing before configuration starts removes the most rework.
| Driver | How it raises effort | How to keep it down |
|---|---|---|
| Companies and legal entities | Each company needs its own chart, fiscal years, cost centers and tax setup, and intercompany transactions need extra mapping. | Confirm the entity count first, build one template company and copy its structure, and decide intercompany scope early. |
| Accounts and hierarchy depth | More ledger accounts and deeper account groups mean more review, more mapping from the source system and more naming decisions. | Start from a standard chart, limit hierarchy depth to what reports need, and fix naming rules before data loads. |
| Open transactions and balances | Higher volumes and older open invoices, payments, stock and orders take longer to clean, map and reconcile. | Carry over only open items, agree the cut-off date, and load records in batches of a few thousand, as the Data Import guidance advises. |
| Tax regimes and rates | Each regime, rate, exemption and reverse charge case needs its own templates, accounts and test transactions. | List the rates by transaction type, reuse tax templates across items where possible, and have a tax adviser confirm the list. |
| Currencies | Each currency needs exchange rate handling, revaluation settings and separate reconciliation of foreign balances. | Limit setup to currencies with real transaction flow, and agree the exchange rate source and revaluation schedule in advance. |
| Reporting requirements | Statutory returns, management packs and consolidated views each need account and cost center mapping that must be tested. | Write the report list before designing the chart, and map each report to the account groups and dimensions it uses. |
| Custom reports or scripts | Server Scripts are disabled by default from version 15 and are not available on Frappe Cloud public shared benches, so custom logic needs a different route and its own testing. | Use standard reports and dimensions first, package any custom code in a custom app, and retest it before each upgrade. |
| Number of environments | Development, staging and production each need the same chart, masters and tax setup, and drift between them causes failed test runs. | Keep setup data as import files under version control and rehearse the opening balance load in staging before production. |
| Approval roles and permissions | Each approver, accountant and read-only role needs role permissions, user permissions and workflow steps that must be tested with real users. | Define the role matrix before setup, and where identities come from a directory, map groups to roles through LDAP login. |
How the accounting setup changes by deployment model
On a self-hosted bench, your team controls the whole stack, so the company, chart of accounts, fiscal years, tax templates and cost centers are configured directly on one site. The setup is easiest to manage when it is built once in a staging site and then repeated in production as a controlled sequence of steps. Because you own the server, you also own the effect of every bench update and migrate on the accounting data.
- Build order: create the company, then the chart of accounts, fiscal year, tax templates and cost centers before any opening balances are entered.
- Staging copy: restore a copy of production to a staging bench and apply the same accounting setup there, recording each step.
- Testing: run a sample sales invoice, purchase invoice, payment, tax calculation and period close on staging before go-live.
- Scripts: keep Server Scripts disabled unless they are enabled deliberately and the code has been reviewed.
- Backups: confirm that a tested backup exists before any migrate step runs in production.
Check that your team can restore the staging site to a known state, because that is the fastest way to repeat the setup if a mapping or default account was wrong.
When several companies share one site, the setup is shaped by decisions about which records are shared and which belong to a single company. Each company needs its own chart of accounts and cost centers, while customers, suppliers and items may be shared or company-specific depending on your process. Intercompany transactions, currencies and user access all need explicit design before the first transaction is posted.
- Shared masters: decide which masters are shared and which are company-specific before creating any transaction.
- Per-company structure: build each company's chart of accounts and cost centers separately, then check that default accounts point to the correct company.
- Intercompany flows: set up intercompany transactions and currencies in staging, then test a transaction that crosses two companies.
- User access: confirm that each user can only see and post for the companies they are assigned to, and test this with real user roles.
- Reporting: agree with finance which consolidated and per-company reports are expected, and test them before go-live.
Ask finance to sign off a written test list covering each company, because a wrong default account in one company is easy to miss when the others look correct.
The accounting data model is the same in a container deployment, but the build and run process changes. The frappe_docker images and Compose files separate MariaDB, Redis, background workers, the scheduler, Socket.io and Nginx into services, and the setup must be performed and verified against those services. Production images and configuration are the appropriate base for accounting data, while the single-file demo setup is marked for short-lived evaluation only.
- Image build: bake any custom apps into the image and tag it, so the accounting setup can be reproduced from the same version.
- Service checks: confirm that the scheduler and workers are running before testing scheduled tasks such as period-end jobs.
- Persistence: verify that database and site file volumes survive container restarts and image replacements.
- Environment parity: confirm that staging uses the same image tag and Compose configuration as production.
- Demo limits: do not use the single-file demo setup for accounting data or for any site that will be kept.
Confirm with your platform team how image rebuilds are approved, because an image change can alter the environment in which the accounting setup was tested.
On Frappe Cloud, the platform operates the bench, so server access and some configuration options are controlled by the hosting service rather than by your team. The most important constraint for accounting is that Frappe Cloud public shared benches do not allow Server Scripts. Any accounting control built as a server script, such as blocking a posting when an approval condition is not met, cannot run on that plan and must be redesigned or moved to a hosting option that permits it.
- Plan check: confirm whether the plan is shared or dedicated and whether Server Scripts are permitted on it.
- Control design: if accounting controls depend on Server Scripts, decide on the alternative and test it before committing to the hosting plan.
- Backups: confirm backup frequency, restore procedures and where backups are kept.
- Support plan: confirm that the Frappe support plan matches the ERPNext major version you run, since warranty coverage depends on it.
- Environments: ask how staging sites are provided and how a production restore is requested.
Check the Server Script limitation in writing before the design starts, because a control removed late in the project often forces rework of the chart of accounts and approval flow.
On an air-gapped network, the accounting configuration is the same, but the build, update and data transfer paths change. Packages, images, app code and updates must cross the boundary through an approved transfer process, and any feature that calls an external service needs review before it is relied on. The security team usually decides what may cross, so that decision should be made before the setup begins.
- Build source: build the bench or image from an internal mirror or a bundle that has been scanned and approved.
- External dependencies: identify features that reach outside the network, such as public Google Sheets imports, outbound email or external OAuth providers, and decide whether each is disabled or replaced.
- Offline staging: test the accounting setup on an offline staging environment built the same way as production.
- Transfer records: document the transfer steps for each update so the same version reaches production without drift.
- Data loading: confirm that the Data Import method works from local files only, and load masters and balances in small batches, as the documentation advises.
Confirm with the security team which artifacts may cross the boundary and who approves them, because that decision sets the pace of every future accounting update.
How to verify ERPNext accounts before go-live
The purpose of verification is to show that the books are right before anyone posts a live transaction, and that a wrong entry is stopped instead of silently accepted. Start with the trial balance. Once opening balances are loaded, run the Trial Balance report for the cut-over date, filtered to the same company and accounts as your legacy export. Each account balance should match the prior ledger, and total debits should equal total credits. Treat any difference as a failed test until you trace it to a specific journal or missing document. Then confirm that the Balance Sheet and Profit and Loss reports reconcile to the same totals.
Next, tie the subledgers to the general ledger. Compare the Accounts Receivable and Accounts Payable reports, grouped by party, with the balances of the matching control accounts at the same date. Every customer and supplier balance should trace to an opening invoice or opening journal entry. A gap usually means a party was posted to the wrong control account or an opening document was skipped. Tax checks come next. Create sample sales and purchase invoices using each Sales Taxes and Charges template and each rate in use, then confirm that tax lines post to the intended liability or expense accounts and that totals match a hand calculation. Ask your tax adviser to confirm treatment of exempt, zero-rated and reverse-charge cases.
If you operate in more than one currency, test exchange gains and losses deliberately. Post a foreign-currency sales invoice, record the payment at a different exchange rate, and check that the difference lands in the Exchange Gain/Loss account set on the company. Then run the revaluation of open foreign-currency balances and confirm the resulting entries and any reversal behave as your accounting policy requires. Role tests confirm that finance users can post only where they are meant to. Create one test user for each finance role, apply User Permissions for Company (and Cost Center where used), and attempt postings to a permitted company and to a restricted one. The restricted attempt should fail, and the failure should appear in the logs you keep as evidence.
Rehearse period closing in staging before production depends on it. Create a Period Closing Voucher for a test period, confirm that entries dated inside the closed period are blocked for users without the right role, and check that the closing balance moves to the retained earnings or equity account you designated. Then test the reopening process your finance team will actually follow, including who approves it. Confirm each of these behaviors against the documentation for your ERPNext version, because settings and report options change between releases. Record the result of every test in a log with the tester, date, expected outcome, actual outcome and supporting screenshot or export.
When a test fails, stop the rollout for that area and do not patch production by hand. First, identify the cause: a wrong account type, a missing opening entry, a mapping error in the import file or a misconfigured tax template. Then restore the staging database from the backup taken before the import, correct the source or configuration, and re-run the Data Import in smaller batches, since the documentation advises importing only a few thousand records at a time. Run the full test sequence again in the same order, because a fix in one area can move balances in another. Only when every test passes on a clean restore should the same steps be scheduled for production.
Access control and data safety for ERPNext accounts
Accounting data is hard to repair once it is wrong, so access and recovery controls need to be set before the chart of accounts goes live. The cards below cover who can change accounts and postings, how company boundaries are enforced, how scripts and identity are governed, and how changes and backups are evidenced.
Role permissions on accounts and postings
Role permissions decide who can create, edit, submit and cancel accounts, journal entries and payment entries. Map each finance role to a short list of document actions, and keep account master maintenance separate from day-to-day posting. Review the Accounting roles in your ERPNext version, then test each role with a sample user before go-live, since default roles often grant more than a clerk needs.
Period closing permissions
Closing a period locks postings for the affected dates, so limit the ability to run closing steps and to adjust closed periods to a small group of senior accountants. Decide who approves the Period Closing Voucher and who may reopen a period, and document the procedure. Confirm how your version handles posting into closed periods and whether that setting is controlled by administrators only.
User permissions by company
In a multi-company setup, user permissions restrict each user to the companies they are allowed to see and post for. Without them, a user with a finance role may open and post in every company's ledgers. Build the restrictions per user or per role, then test them with cross-company documents such as inter-company transactions, shared customers and shared suppliers, which are the usual places where restrictions leak.
LDAP group mapping to finance roles
If finance staff sign in through LDAP against Active Directory or OpenLDAP, ERPNext can map directory groups to ERPNext roles at each login. Agree the mapping with the directory owners, because a broad group mapped to an accounting role grants access to every user in it. Remove a user's directory group membership and confirm that ERPNext revokes the role at the next login, and keep a local administrator account for recovery.
Server Scripts kept disabled
Server Scripts run Python on document events and can change postings without a visible approval step. From version 15 they are disabled by default and must be enabled with the server_script_enabled setting. Keep them disabled unless a specific, reviewed need exists, and require code review, a staging test and a named owner for any script that touches accounts or ledger entries. Public shared Frappe Cloud benches do not allow them.
Audit trail for chart of accounts changes
Account creation, renaming, moving and disabling change how every future report reads, so these changes need a record of who made them and when. Confirm which account-related DocTypes have change tracking enabled in your version, enable it where it is missing, and review the version history on a schedule. Pair it with a change log for account structure decisions, because the history shows what changed but not why.
What finance and IT must keep running after accounting goes live
Once the chart of accounts, tax setup and cost centers are live, the accounting configuration stays correct only if someone checks it on a fixed routine. Each recurring task in this section needs a named owner, usually a finance controller for ledger work and a platform administrator for backups, permissions and upgrades, and each owner needs admin time in their calendar. Without named people and scheduled time, the routine tends to slip during month-end pressure, and the problems surface later as unexplained differences in reports that auditors or lenders read.
Reconcile the trial balance at the end of every accounting period. The finance owner should compare the Trial Balance report against the receivable, payable and bank sub-ledgers, and investigate any account where the balances do not agree before the period is closed. Take a backup of the site immediately before each period closing run, and record which backup corresponds to which closing so the team can restore a known state if a posting error is found later. Confirm the backup and restore steps with your administrator, since the mechanics belong to your backup design.
Document the chart of accounts, tax templates and cost center rules, and name the owner of each. The owner should approve every change, because a renamed account, a new tax rate or a moved cost center can alter how historical and future entries are grouped. Keep a dated change log that states the reason for each change and who approved it. Ask your implementation partner or internal team to confirm which settings can still be edited after transactions are posted, since that limit determines how much review each change needs.
Review user permissions after every staff change, including joiners, movers and leavers. Check role assignments, User Permissions limiting access by Company or Cost Center, and any account that can post, submit or cancel accounting documents. Upgrades and custom apps need the same discipline. Before a version upgrade reaches production, the administrator and finance owner should run the upgrade on a staging copy, confirm that ledger totals and tax calculations match, and check that custom apps still post to the expected accounts. Confirm the release notes and compatibility status for your version with the vendor before you schedule the change.
Questions buyers ask about ERPNext accounting setup
Can our finance team set up the ERPNext chart of accounts without a partner?
Yes, many finance teams can, provided one person owns the design and understands how ERPNext groups accounts, sets root types and links company defaults to specific accounts. ERPNext is free and open source under GPL-3.0, so there is no license fee, and the cost of a self-run project is mainly staff time, testing and hosting. A partner usually adds value where the structure has several companies, currencies or tax regimes, where opening balances must reconcile to audited figures, or where the team has no one who has configured the module before. Ask whether your team can produce a written account structure, a test plan of sample transactions and a period-close checklist before deciding.
What does an ERPNext accounting setup need from our finance staff?
The work needs decisions from the controller and time from the people who post and reconcile daily. Finance staff typically approve the account hierarchy, cost center structure, fiscal years, tax codes and reporting requirements, then review how each decision maps to statutory and management reports. They also supply trial balances and subledger listings for opening balances, confirm how receivables, payables, bank and inventory accounts reconcile, and run test transactions through invoices, payments, journal entries and period closing. Plan for named reviewers with enough availability during design and testing, because delays in finance sign-off are one of the most common causes of schedule slippage.
What drives the cost and effort of an ERPNext accounting project?
The main drivers are the number of companies, currencies, tax jurisdictions and reporting views, the state of the existing chart of accounts, the volume and quality of opening balances, and any integrations with banks, payroll or e-commerce. One-time costs cover design, configuration, data preparation, testing and training. Recurring costs include hosting, support and upgrades. Hosting is a separate decision: the ERPNext pricing page lists Frappe Cloud shared site hosting from 5 US dollars per month and servers from 20 US dollars per month for shared instances and 125 US dollars per month for dedicated servers, while self-hosting carries no license fee. Ask for a quote that separates design, build, data load, testing and training, and that states which hosting option it assumes.
How do multi-company and multi-currency setups change ERPNext accounting?
Each company needs its own default accounts, fiscal year, cost centers and chart structure, and intercompany transactions need an agreed method for matching and eliminating balances. Multi-currency adds more decisions: the base currency per company, the exchange rate source, accounts for realized and unrealized exchange gains and losses, and a period-end revaluation routine for foreign-currency receivables, payables and bank accounts. Reporting also changes, because consolidated views need consistent account mapping across entities. Confirm the exact settings and reports available in the ERPNext version you select, and ask the partner to demonstrate one intercompany and one foreign-currency transaction end to end in a test site before go-live.
Does DeployOpen issue audit reports for our ERPNext accounting controls?
No. DeployOpen does not issue audit reports, attestations or certifications. DeployOpen plans, implements and documents the system and prepares the evidence an assessment will need, such as configuration exports, role and permission matrices, change records, reconciliation workpapers and period-close checklists. Independent auditors or certification bodies perform the assessment and issue any report. Ask your auditor early which controls they expect to test and in what format they want evidence, so the configuration and records are designed to answer those questions from the start.
Which ERPNext version should a new accounting setup target?
Choose a version that is listed as supported on Frappe's supported versions page at the time you start. According to that page, version 14 reached end of life on January 31, 2026, version 15 is planned to be supported until the end of 2027, and version 16 until the end of 2029. A longer support window reduces the number of upgrades you must plan, so a newly built accounting setup usually targets the version with the most runway. Both supported major versions receive frequent minor releases, so plan a routine update schedule. Confirm the current support status directly on that page before you commit, because support plans can change.
What should a written quote for ERPNext accounting setup include?
A useful quote states the scope in deliverables rather than in general terms. It should list the design workshops, the number of companies, currencies, tax setups, fiscal years and cost center structures covered, the opening balance load and its reconciliation method, the test cases and acceptance criteria, training sessions and the documentation handed over. It should name the hosting assumption, whether self-hosted or Frappe Cloud, and what is excluded, such as custom reports or integrations. Check the payment milestones, the process for change requests, the client responsibilities such as staff time and data extracts, and the terms for post-go-live support. Most engagements are fixed-scope and agreed in writing before work starts, so ask for these items to be in the contract.
Can we change the ERPNext chart of accounts after go-live?
Often yes, but changes after transactions are posted need planning. Adding new accounts is usually straightforward, while renaming, moving or merging accounts that already carry ledger entries can affect reports, closed periods and reconciliations. Restructuring a group account, changing an account type or altering default mappings can also change how future postings are classified. Confirm the behavior for your ERPNext version in its documentation, then test the change on a copy of the production data, review its effect on the trial balance and prior period reports, and schedule it outside period close. Keep a record of each change for audit evidence.
How DeployOpen scopes, builds and hands over ERPNext accounting
DeployOpen plans and implements ERPNext accounting setup inside your own infrastructure, whether on your servers, in your cloud account or on Frappe Cloud. Work is agreed as a fixed-scope project with written deliverables, and ongoing support is available as a retainer.
How we scope
- Written scope lists the companies, fiscal years, currencies and tax regimes the chart of accounts must cover.
- We confirm which cost centers, multi-company structures and opening balance sources are in or out of scope.
- We agree the hosting target, whether self-hosted or Frappe Cloud, before any configuration begins.
How we build
- We draft the chart of accounts and tax templates with your accounting team and review them before loading.
- We configure fiscal years, cost centers and currencies in a staging site, then test posting and reporting paths.
- We document every setting, opening balance step and period closing routine in the handover pack.
How we hand over
- Your finance and administration staff receive a walkthrough of the configured accounts and closing checklist.
- You receive the configuration record, test results and a list of settings that need owner sign-off.
- Admin access and backup responsibilities are transferred in writing so that ownership after go-live is clear.
How we support
- Ongoing support covers configuration changes, version upgrades and test runs of accounting setup after updates.
- Support is available as a retainer, scoped separately from the original fixed-scope project.
- Confirm with us in the quote which support levels, response expectations and upgrade paths apply to your environment.
