How Coding Profiles and Policies Work
A coding profile is a saved set of coding defaults. Instead of picking the same ledger account and cost code on every fuel receipt, you build a Fuel profile once and it fills those in with one pick. A policy is the list of profiles a person is allowed to choose from.
This guide is for admins planning how their team's coding gets pre-filled. It explains how profiles and policies behave. For the step-by-step setup, see Coding Profiles and Policies.
This guide covers:
- What a profile sets, and what it never touches
- Standard and overhead profiles
- A worked Fuel example
- How policies and default profiles limit what a person can pick
- How profile values resolve for your ERP
- What editing or deleting a profile changes
What a profile sets
A coding profile carries up to six values. Only Profile Name is required, so a profile can set one value or all of them.
| Field | Where it lands |
|---|---|
| Vendor | The expense header |
| Department | The expense header |
| Ledger Account | Every line item |
| Cost Code | Every line item |
| Cost Type | Every line item |
| Description | The expense description, if nobody typed one |
A profile never sets the project
This is the most important thing to know about profiles, and it explains most of how they behave.
Profiles are company-level. They have no project field, and every option you pick when building one comes from a company-level list. Applying a profile never sets, changes, or clears the project on an expense.
The person coding the expense still picks the job. The profile handles everything that doesn't depend on which job it is.
Standard and overhead profiles
Every profile has a Profile Type, and the type decides whether the expense is job-costed:
| Type | Job-costed | Carries cost code and cost type | Effect on project |
|---|---|---|---|
| Standard | Yes | Yes | None |
| Overhead | No | No | Removes the Project field |
Standard is the default. Use it for spend tied to a job: fuel burned on a job, materials for a specific build, equipment rental for a site.
Overhead is for spend that never touches a job: office supplies, software, the shop's own utilities. An overhead profile has no cost code or cost type fields at all. They're neither shown when you build it nor saved.
Applying an overhead profile to an expense that already has a project drops the project, along with the sub job and budget tied to it. Check the type before applying a profile to an expense someone has already coded.
Example: a Fuel profile
Fuel is the case profiles were built for. A crew fills up several times a week at truck stops, always hitting the same account and cost code, and almost always on a different job.
A Fuel profile sets everything except the job:
| Field | Value |
|---|---|
| Profile Name | Fuel |
| Profile Type | Standard |
| Ledger Account | Your fuel expense account |
| Cost Code | Your fuel or equipment cost code |
| Cost Type | The cost type fuel posts to |
| Vendor | Leave empty |
| Description | Optional, for example Fuel purchase |
Leave Vendor empty here. Setting it would stamp every fill-up with the same truck stop, no matter where the fuel was bought.
A driver submits a pump receipt, the profile fills in the accounting side, and the reviewer picks the job. That's the whole interaction.
The finished profile looks like this in the editor:
How policies limit what a person can pick
A policy is a named group of profiles. Assigning one to a person limits them to those profiles, so a driver sees the three that apply to them instead of all forty your company has built.
Profiles, policies, and users fit together like this:
The relationship only runs one way:
- A policy holds many profiles, and a profile can sit in several policies. A shared Fuel profile can be in both a Field policy and a Fleet policy.
- A person has one policy. Assigning a second one replaces the first.
Since each person gets one policy, build policies around roles, not around categories of spend.
Who a policy restricts
A policy only narrows the list for non-admins, and only once one is assigned:
| Person | Policy assigned | Profiles they see |
|---|---|---|
| Admin | Any, or none | All profiles |
| Non-admin | A policy | Only the profiles in that policy |
| Non-admin | None | All profiles |
A person with no policy isn't restricted at all. So a rollout gets narrower as you go: until you've assigned everyone, the people you haven't reached yet still see every profile. After creating your policies, check Settings > Users for anyone whose Coding Profile Policy is still empty.
How a default coding profile works
A person can also have a Default Coding Profile. It's a different tool from a policy:
| Setting | What it does |
|---|---|
| Coding Profile Policy | Limits which profiles the person can pick from |
| Default Coding Profile | Applies that profile to every receipt they submit, and rejects a submission that uses any other profile |
Use a default for someone whose spend is all one kind, like a driver who only ever buys fuel. Leave it empty for anyone who needs to choose.
Both are set per person under Settings > Users.
How profile values resolve for your ERP
Profiles are company-level, but cost coding is often project-level. So when a profile is applied, Agave translates its stored cost code into whatever the selected project needs. You don't configure any of this. It explains why the same profile can resolve to different codes on two expenses coded to different jobs.
For most ERPs, the stored value is used as-is. Three systems re-scope it to the project:
- Foundation: the cost code is rebuilt as a project-level code using the account's default sub job, and that sub job is applied to the line. Foundation cost types are company-level, so only the cost code changes.
- Sage Intacct, on project-level accounts: both cost code and cost type are re-scoped to the project, using the sub job on the expense, or the account default if there isn't one.
- CMiC, on accounts that aren't company-level: the cost code is re-scoped to the project.
Two systems have exceptions:
- CMiC and ledger accounts. CMiC derives the ledger account from the project during sync, so Agave doesn't apply a profile's ledger account to a CMiC expense that has a project. On an overhead CMiC expense, the profile's ledger account does apply.
- Spectrum and cost codes. On a Spectrum account that doesn't use company cost codes, profiles carry no cost code at all.
What editing or deleting a profile changes
Editing only changes what the profile applies from now on. Expenses already coded with it keep their values, so changing your fuel cost code doesn't recode last month's fuel.
Deleting is permanent. There's no archive or deactivate option.
Before deleting a profile, check whether it's in any policy or set as anyone's Default Coding Profile under Settings > Users.
Related guides
- Coding Profiles and Policies: creating profiles and policies and assigning them to people
- Coding an Expense: applying a profile while coding
- How Receipt Matching and Automatic Coding Work: what's filled in before a profile is applied
- Field App Settings: which fields a field user sees when picking a profile
- Transaction Settings: rules that apply a profile automatically