Fixed Assets, Expenses & Contracts
| Site: | Learn at Merupu AI |
| Course: | SamvraCore ERP |
| Book: | Fixed Assets, Expenses & Contracts |
| Printed by: | Guest user |
| Date: | Tuesday, 27 October 2026, 7:30 AM |
Description
Asset depreciation, employee expense reimbursement, and contract lifecycle management.
1. The Fixed Asset Register
The Fixed Assets module tracks a company's long-lived, capitalised property. The AssetsPage holds the asset register, where each asset records an asset code, a useful life expressed in months, a warranty expiry date, and its accumulated depreciation. These fields let the organisation identify each asset uniquely, know how long it is expected to remain in service, and see how much of its value has already been written down.
Assets are organised with two supporting dimensions. Categories (CategoriesPage) group assets and can define default depreciation methods, so a new asset in a category can inherit the appropriate method. Locations (LocationsPage) record where assets physically reside, supporting physical tracking across the organisation.
Each asset also tracks purchase and disposal information along with its current value and accumulated depreciation, giving a continuous picture of what the asset is worth on the books.
A typical flow: an asset is created with its code, assigned to a category that supplies a default depreciation method, placed at a location for physical tracking, and given a useful life in months and a warranty expiry. From there the asset participates in depreciation and, eventually, disposal. The register thus serves as the single source of truth for what the organisation owns, where it is, and how its book value is changing over time.
2. Depreciation Methods and Posting
Depreciation is handled through the DepreciationPage and automates the periodic write-down of asset value. SamvraCore supports three depreciation methods: Straight-line, Declining balance, and Sum of years digits. A category can set a default method that its assets inherit, and depreciation is calculated against the asset's useful life.
Depreciation integrates with the general ledger through accumulated-depreciation accounts, and the module generates journal entries for depreciation. This means running depreciation does not just update a figure on the asset record; it produces accounting entries so the financial statements reflect the expense and the growing accumulated depreciation.
The module also produces depreciation schedules and forecasts, allowing the organisation to see the planned write-down of an asset over its life. The backend provides an action to run depreciation and an endpoint to retrieve the depreciation schedule.
A worked example: an asset is assigned the straight-line method and a useful life in months. Running depreciation for a period calculates the period's depreciation, increases the asset's accumulated depreciation, lowers its current value, and generates the corresponding journal entry against the accumulated-depreciation account. The depreciation schedule shows how the asset's value is expected to decline across its remaining useful life, supporting planning and review.
3. Asset Disposal and Reporting
Fixed assets do not stay on the books forever. SamvraCore supports an asset disposal, scrap, and sale lifecycle with sale-proceeds tracking, so when an asset is retired the system records how it left service and, for a sale, what was received for it. The backend provides a dedicated action to dispose of an asset, and purchase and disposal information is held on the asset record itself.
Reporting is delivered through Asset Reports (AssetReportsPage). These include book value reporting and an asset-value distribution, as well as breakdowns of assets by location and by category. In accounting terms these correspond to an asset register, a depreciation schedule, and an asset valuation view.
Together, the register, depreciation, and disposal give a full lifecycle. An asset is acquired and capitalised, depreciated over its useful life with accumulated depreciation and current value kept current, and finally disposed of by scrap or sale with proceeds tracked.
A worked example: an asset reaches the end of its useful life and is sold. The disposal action records the sale and its proceeds, removing the asset from active depreciation. Asset Reports then reflect the change: book value reporting shows the reduced total, the by-location and by-category breakdowns drop the disposed item, and the asset-value distribution updates to the remaining portfolio.
4. Expense Claims and Their Workflow
Expense Claims let employees seek reimbursement for money they have spent. The module is surfaced through ExpenseClaimsPage, ExpenseClaimDetailPage, and NewExpenseClaimPage. Each claim records a claim number, a date, an amount requested, and an amount approved, so the organisation can see both what was asked for and what was ultimately authorised.
A claim is built from line items with attached receipts, and lines can carry category and project allocation, so each expense is classified and, where relevant, charged to a project. Claims support multi-currency, allowing expenses incurred in different currencies to be captured.
Claims follow a defined status workflow: Draft, then Submitted, then Approved, then Paid. The backend provides explicit actions to submit, approve, reject, and mark a claim as paid, so each transition is a deliberate operation. Approved claims feed a via-payroll reimbursement flow, letting reimbursements be paid through payroll.
A worked example: an employee creates a new claim, adds line items with receipts allocated to categories and a project, and submits it. The claim appears for approval, where an approver authorises an approved amount that may match or differ from the requested amount. Once approved, the claim is paid, optionally through the payroll reimbursement flow, moving it to the Paid state and completing the cycle.
5. Expense Categories, Policies, and Approvals
Expense Claims are governed by categories and policies. Expense Categories (ExpenseCategoriesPage) classify what each expense is for, and claim line items are allocated to these categories. Expense Policies (ExpensePoliciesPage) define the rules claims must obey, including spending limits, approval thresholds, category limits, receipt requirements, and per diem rates.
These policies shape approval. The module uses a multi-level approval workflow with manager approval, amount-based routing so that larger claims escalate appropriately, and batch approval support for handling many claims efficiently. Claims awaiting action appear in a Pending Approvals queue (PendingApprovalsPage), the same centralised queue pattern used across SamvraCore's approvable documents.
The module also provides Expense Reports (ExpenseReportsPage) for analysing claim activity.
A worked example: an organisation defines categories such as travel and meals and sets a policy with a per-category spending limit, a receipt requirement, and an approval threshold above which a claim must escalate. When an employee submits a claim, amount-based routing sends a small claim to a manager and a larger one up the chain. Approvers can clear multiple claims at once through batch approval from the Pending Approvals queue, and Expense Reports summarise the resulting spend.
6. Managing Contracts
The Contracts module manages customer and vendor agreements through ContractsPage, ContractDetailPage, and NewContractPage. Each contract records a title, a type, a period, a renewal term in months, an auto-renew setting, its terms and milestones, and the parties to the agreement.
Contract types cover Sales, Service, Subscription, NDA, and Other, letting agreements be classified by their nature. A contract carries start and end dates with renewal tracking, a contract value, and payment terms. Contracts can also have documents attached, with version control and signature tracking on those files.
A contract follows a status lifecycle of Draft, Active, Expired, and Terminated. The backend provides actions to activate, terminate, and renew a contract, so these transitions are explicit operations rather than free-form status edits.
A worked example: a service agreement is created as a Draft with its title, type, period, value, payment terms, and a renewal term in months, and the parties are recorded. The agreement is activated so it becomes Active and its terms and milestones can be tracked. When the period ends it either expires or is renewed; if the relationship must end early, the contract is terminated through its dedicated action. Attached documents keep signed copies under version control with signature tracking.
7. Contract Renewals and Reporting
Renewal management is central to the Contracts module. Contract Renewals (ContractRenewalsPage) distinguish auto-renewing contracts from those renewed manually. Because each contract carries an auto-renew flag and a renewal term in months, the system can treat an auto-renewing agreement differently from one that requires a deliberate renewal decision.
The module supports renewal reminders, auto-renewal configuration, and a renewal history, so the organisation is prompted ahead of expiry, can control automatic renewal behaviour, and can see how a contract has been renewed over time. The backend provides an endpoint for upcoming renewals and a renew action on a contract.
Contract Reports (ContractReportsPage) provide a distribution view of contracts and expiring-soon alerts that highlight agreements approaching their end dates, helping staff act before a contract lapses unexpectedly.
A worked example: a subscription contract is set to auto-renew with a renewal term of twelve months. As its end date approaches, a renewal reminder and an expiring-soon alert flag it. Because it is configured to auto-renew, it renews automatically for the next term, and the renewal is captured in the renewal history. A separate manually renewed contract instead surfaces in the renewals view for a deliberate decision, and the distribution report gives management an overview of the whole contract portfolio.