Working in Finance

Daily Operating Model

Finance works best when teams treat the module record as the source of truth and use tasks, tickets, workflows, and reports as supporting surfaces. The flows below are the common day-to-day paths to validate during setup and train users on after go-live.

Flow 1: Set up chart of accounts

1. Open Chart of Accounts and create top-level GL accounts.
2. Add account code, type, name, and active status.
3. Create cost centers used for departmental reporting.
4. Create budget votes for budget-controlled spend.
5. Configure posting profiles for subsidiary modules.
6. Run a small guided transaction or journal test.
7. Review ledger output for correct debit and credit movement.
8. Lock down account maintenance permissions before go-live.

Flow 2: Post and review a journal

1. Open Journals and create a new journal.
2. Add balanced journal lines with GL account, amount, description, and dimensions.
3. Attach cost center or budget vote where reporting requires it.
4. Save as draft while finance reviews the entry.
5. Post only after totals balance and supporting evidence is attached.
6. Review Ledger to confirm posted entries.
7. Void through the journal action when reversal is required.
8. Use trial balance to confirm the entry lands in the expected account group.

Flow 3: Manage budget-controlled spend

1. Create or review budget votes for the period.
2. Associate spend requests, requisitions, or accountable transactions with the vote.
3. Monitor drawdown through budget vote ledger entries.
4. Investigate transactions that would exceed budget policy.
5. Approve, reject, or route exceptions through workflow.
6. Review cost-center ledger impact after posting.
7. Use reports to compare budget, actual, and remaining balance.
8. Close or archive budget votes according to finance policy.

Flow 4: Run financial reports

1. Open Reports and choose trial balance, income statement, balance sheet, or ledger detail.
2. Set reporting date range and dimensions.
3. Check whether journals and subsidiary postings are complete for the period.
4. Review unusual balances or missing cost-center movement.
5. Export or share the report with the intended audience.
6. Use workflow tasks for follow-up on reconciliation issues.
7. Close the reporting period only after exceptions are resolved.
8. Keep report assumptions documented for audit.

Day-To-Day Controls

• Start from the launchpad route, then use filters and saved views to focus on records needing action.
• Use status fields and lifecycle actions instead of free-text notes for important state changes.
• Attach documents, comments, or related records when a decision needs evidence.
• Create tasks when work leaves the current owner or needs a due date.
• Create tickets when the work is customer-facing or belongs in a support/service queue.
• Use workflows for predictable notifications, approvals, escalations, and cross-module updates.
• Use reports for recurring team reviews rather than exporting ad hoc lists every time.
• Keep permissions tight enough that users see the records they need but not sensitive configuration.
• Review rejected, cancelled, failed, or overdue records every week.
• Keep integrations aligned with the same lifecycle users follow in the UI.

Exception Handling

• If a record is stuck, check owner, status, required fields, approvals, and linked records before editing downstream data.
• If a workflow did not run, confirm the event name, trigger filter, record permissions, and service-user access.
• If reports look wrong, inspect whether the source record is draft, cancelled, archived, or missing a required dimension.
• If an integration created bad data, fix the source mapping and then repair the affected records through supported actions.
• If users cannot see a route, review launchpad access, module roles, page permissions, and tenant feature flags.
• If a public or embedded route exposes too much, disable exposure first and then correct permissions or filters.
• If two modules disagree, choose the module that owns the lifecycle as the source of truth and update the other from it.
• If a record supports audit, void, archive, or cancel it instead of deleting it whenever possible.

Reporting Rhythm

• Daily: review new, overdue, failed, rejected, and pending-approval records.
• Weekly: review owner workload, aging, status changes, and recurring exceptions.
• Monthly: review configuration, permissions, integration failures, and report definitions.
• Quarterly: review whether custom pages, workflows, and API access still match real operating practice.
• After major process changes: rerun one end-to-end flow with a pilot record before enabling it broadly.

Cross-Module Handoffs

• To Base objects: pass stable identifiers, owner, status, dates, and any dimensions required for reports.
• To tasks: include a precise action, due date, source record link, and escalation owner.
• To tickets: include requester, priority, support context, and the module record link.
• To workflows: prefer explicit create, update, approval, and status-change triggers.
• To reports: keep dimensions consistent across records so dashboards can group accurately.
• To integrations: use /reference/finance for namespace and intent details.