A workshop starts with one service revenue account, then adds preventive maintenance, repairs, and spare parts sales. Management wants to know which activity supports the business, while accounting needs each transaction posted correctly. Subaccounts can help. Creating one for every customer, technician, and month can instead make the chart difficult to use. Start with decisions people need to make rather than everything you could possibly classify.
Decide which question needs an account
Ask who will use the detail and what they will do with it. Comparing monthly maintenance and repair revenue may justify stable subaccounts. Finding one customer's invoice may already be possible through document and counterparty records. An account should not replace information belonging on a sales line or reference. Check whether an existing report answers the question before adding another ledger category.
Write a short definition for each proposed account: included activity, excluded activity, and an example. Preventive maintenance might include scheduled services but exclude standalone parts and fault repairs. If two colleagues cannot classify the same transaction consistently, refine the definition before creating codes. A good-looking name does not make the chart usable during a busy morning of document preparation.
Respect Tario's existing structure
Tario's ledger includes an account tree. You can search names or codes, inspect activity, and create accounts with category, type, and parent. A subaccount must belong to the company and have a category and type compatible with its parent. Validation prevents inconsistent structures without deciding the commercial meaning of the new level. Review that meaning with the person responsible for accounting.
System accounts have purposes used by the posting engine. Tario allows renaming them but not reclassification, archiving, or disabling journal posting. Do not turn receivables into revenue to change a report's appearance. Add compatible detail in the right place and preserve system purposes. Tree order and visible labels do not replace an account's actual role.
Use few levels and stable codes
The workshop might group services and distinguish preventive maintenance from repairs, with compatible detail for spare parts sales. Actual codes should follow the company's chart rather than copying an illustrative numbering scheme as a requirement. Leave room for growth and avoid placing a year in every permanent account. A new account each month fragments annual comparisons into repeated aggregation work.
Consistent names make searching easier: maintenance revenue, repair revenue, transport expense. Avoid nearly identical labels such as general maintenance, miscellaneous maintenance, and other maintenance unless staff can distinguish them. Agree on abbreviations and authority to add accounts. If anyone creates an alternative after a short unsuccessful search, duplication eventually spreads into every report. Searching first and requesting a justified addition reduces later cleanup.
Separate grouping from posting
Tario's account behavior settings include whether journal entries are allowed, permitted source, and effective dates. An account intended only for grouping should not receive accidental postings. Review that choice and test where a transaction lands. Adding a parent does not automatically transform its historical lines into movements of newly created children. Account structure and posted transaction lines are separate.
- Define category, type, and parent before choosing the final label.
- Decide whether the account receives entries or only organizes the tree.
- Check currency, source restrictions, and effective dates for its intended use.
- Identify products or processes that need to select the new account.
If a catalog service should use a specific revenue account, review its product assignment. Tario's documentation supports that relationship so documents use the configured account. Creating a subaccount without updating the assignment may leave it empty. Use a safe test transaction or reviewed draft and the permitted workflow to verify behavior. Do not issue a real invoice solely to experiment with your chart.
Test ambiguous transactions
Choose mixed cases before finalizing the design. A repair with parts may need separate lines. A visit without repair may belong to a different service. A discount may reduce the transaction's revenue rather than justify an improvised account. Ask staff to classify these cases using the definitions and resolve disagreement now. The chart should support repeatable work without requiring management consultation for every document.
Review a month of activity with the accounting owner afterward. Check whether detail totals make sense and empty accounts indicate forgotten assignments. Look for postings still reaching generic accounts through old configuration. Record what changed and when. Creating a subaccount does not promise historical reorganization; comparisons must account for the structure used in each period and where earlier movements remain.
Retire accounts without erasing history
Tario retains accounts and history. Ordinary accounts are retired through archiving rather than deleting evidence. Review active assignments and staff usage first. Archived accounts can remain necessary to explain historical balances and are available through the archived-account view. Keep system accounts available. Changing future selection should not prevent someone from reconstructing an already posted transaction.
Maintain short definitions in your company's procedure, with an approval owner and criteria for additions. Revisit the chart when a genuinely different activity appears rather than whenever a customer changes. A useful subaccount has a reason, receives expected postings, and produces a comparison somebody uses. That lets the workshop distinguish revenue without duplicating categories or losing its connection to source documents.