FiscFlow Overview
FiscFlow exists to do one thing well: get your district's people paid correctly - on time, every time. It replaces paper forms and email chains for timesheets, personnel requisitions, and document submissions, routing each through the right approvals with one always-current view of where everything stands.
What FiscFlow does
A submission is anything that needs review before it's final. FiscFlow takes a submission, routes it to the right people in the right order based on rules your district configures, and records every step. Everyone sees the same live picture: what the request is, who has acted, who it's waiting on now, and what happens next.
Create
Someone fills out a submission. The form shows only the fields that submission type actually needs.
Route
On submit, FiscFlow assigns it to the first approval step automatically, following the workflow tied to that type.
Finalize
Each step approves or rejects (a reject can send it back a chosen distance). When the last step approves, the submission is finalized - and appears in reports.
The kinds of submission
A submission's shape is configured, not hard-coded - a Category and Type decide what fields and content it has. In practice, districts use three broad kinds:
| Kind | What it's for | Carries |
|---|---|---|
| Timesheet | Recording hours worked or absence for a position. | Hours entries, tied to an employee assignment. |
| Personnel Requisition (PR) | Requesting/authorizing a position and its funding. | A personnel requisition; no employee assignment. |
| Document | Routing supporting documents for sign-off. | Document attachments with values. |
How districts actually use FiscFlow
These three kinds aren't a fixed sequence you march through - they're modular capabilities your district turns on for what it needs. Districts run FiscFlow in any combination, and mix and match freely:
Personnel Requisitions
Payroll, budget, accounting, and school admin staff create and approve the positions they need. Some districts handle PRs here; others keep them in another system and enter them only so accounts can route timesheets.
Timesheets
Employees - or office admins on their behalf - record hours each pay period and submit them for approval, ready to export to payroll.
Documents
Anything needing document sign-off: reimbursements, field-trip approvals, permission slips, and more - often available year-round.
A district might start with just one and add others over time; the pieces are designed to combine. Whichever they use, the same routing model applies underneath - one shared pool of work, filtered to each person by their role and approval filters. If you've ever wondered why something did or didn't reach you, start with Why can't I see or approve this?
Key concepts
A handful of ideas explain nearly everything in FiscFlow.
Submission
The request itself. Every submission has a Category and Type that decide its fields, its approval workflow, and its schedule of submission windows.
Submission window (pay period)
The dated period a submission belongs to. Windows come from a schedule on the type. Some windows are open-ended; others have restricted dates that create a hard deadline. See Submission windows.
Workflow & steps
The ordered list of approval steps a submission must pass. Each step names a role, not a person, so the right people are found automatically even as staff change. A role can appear more than once, and the submission returns to it each time.
Role
What a person can do - expressed as capability switches like can approve submissions, can approve employee assignments, and can view work items. You "hold" a role by having an employee assignment that carries it in the current fiscal year.
Approval filter
A rule attached to an approver's assignment that says which submissions they may act on - by account, site, classification, and more. Filters are either Allow or Deny, and the golden rule is: at least one Allow must match, and no Deny may match. See Approval filters.
Employee Assignment (EA) - the "position"
A person placed into a position (a Personnel Requisition) for a date range, at one or more sites, with a role. Assignments may themselves require approval before they can be used.
Because workflow steps name roles, you rarely rebuild a workflow when someone leaves - you reassign the role and the workflow keeps working. What each role member actually receives is then narrowed by their approval filters.
The lifecycle of a submission
Every submission reports a status derived from where it is in the process:
| Status | Meaning |
|---|---|
 Draft | Being filled out; not yet submitted. Only its owner sees it. |
 Needs Revision | An approver returned it. It's back with the creator to fix and resubmit. |
 Waiting on Approval | Submitted and sitting at an approval step. Where most submissions spend their time. |
 Waiting on HR Approval | Submitted, but its employee assignment hasn't been approved yet, so approval can't start. |
| Waiting on Position Control # | Submitted, but the requisition still needs a Position Control Number. |
 Approved | Every step signed off and it was finalized. The request is done and appears in reports. |
How a submission moves between these - and exactly what makes each button available - is covered in Submissions & lifecycle and Approve, reject & recall.
Before you configure anything
A few District Options decide whether approvals are even required and how requisition numbers work. Because two of them seed defaults onto every record you create afterward, review them first.