Transaction Coding

Transaction coding decides where a transaction lands in the ledger and which department, location, class, or vendor it belongs to. Settings → Transaction Coding holds four sections that answer one question in sequence:

1. Which accounts and dimension values exist?
2. Which of them are allowed on a specific transaction?
3. Which spend must a person look at, whatever the coding?

Coding is separate from categories. A category drives Eigenn reporting. A GL account drives the accounting ledger. See Transaction Categories and Rules for categories.

Prerequisites

• A team workspace.
• Owner or Member access. Coding settings are team writes.
• A connected accounting provider, if you want to import the chart of accounts instead of typing it.

Chart of accounts

The chart lists the GL accounts that a transaction can be posted to. Each account holds a code, a name, and optional account type, currency, and external ID.

Until the chart holds accounts, the GL picker on a transaction can offer only codes that someone already typed on another transaction. A new ledger account is then unreachable, and a typo becomes permanent.

Import from a connected provider

Eigenn shows an Import from button for each connected provider that can list a chart of accounts. QuickBooks Online and Xero support this import. The other accounting providers have no such endpoint, so Eigenn hides the button rather than offering an import that always fails.

The import result reports how many accounts Eigenn imported and how many it archived. If the import stops early because the provider list is long, Eigenn archives nothing on that run, so a partial read cannot retire accounts that still exist.

Add an account by hand

1. Open Settings → Transaction Coding.
2. In Chart of accounts, enter a Code and a Name.
3. Enter an Account type if you use one.
4. Select the add control.

Select Archive to retire an account. Select Restore to bring it back. An archived account keeps its history and stops appearing as a new coding option.

Dimensions

Dimensions fill the pickers on every transaction. Eigenn supports four:

Each value holds a display Name and a stable Value key. If you leave the key blank, Eigenn derives it from the name: lowercase, with each run of non-alphanumeric characters replaced by a hyphen. Keep the key equal to the key that your accounting system uses.

To add a value, select the dimension tab, enter the name and optional key, then submit. Use the remove control to delete a value.

Coding constraints

A constraint narrows the values that one field can take, based on how the rest of the transaction is coded. A rule corrects a transaction after it is coded wrong. A constraint stops it from being coded wrong.

Eigenn enforces a constraint when a transaction is saved, not only in the dropdown.

Create a constraint

1. Enter a Name.
2. Select the target field: GL account, Category, Department, Location, or Class.
3. Build the condition that decides when the constraint applies. The condition uses the same fields and operators as transaction rules.
4. Enter the allowed values as a comma-separated list.
5. Turn on required if the field must not be empty when the condition matches.
6. Create the constraint.

Which constraint wins

More than one constraint can match the same transaction. Eigenn applies the most specific one and ignores the rest.

Specificity is decided in this order:

1. The constraint with more condition predicates wins.
2. On a tie, the constraint that permits fewer values wins.

Eigenn does not combine matching constraints. Combining them would let a broad constraint widen a narrow one, which would remove the guardrail.

A field with no matching constraint accepts any value.

Spend policies

A spend policy raises a flag when a transaction meets a condition. Policies do not block the transaction. They mark it for a person.

Each policy holds a name, a condition, a flag kind, and a message that the reviewer sees. If you leave the message blank, Eigenn uses a summary of the condition, so a flag never appears without a reason.

Supported flag kinds:

Use the switch on a policy row to enable or disable it. A disabled policy is skipped during a sweep.

Run a check

Select Check transactions now to apply every enabled policy. The sweep covers up to 2,000 transactions and reports how many it flagged and how many it cleared.

The sweep both raises and clears flags. When a transaction no longer meets a policy condition, Eigenn deletes the still-open flag for that policy. A flag that outlives its cause trains reviewers to ignore flags.

Eigenn clears only open flags. A flag that a person already resolved, dismissed, or acknowledged stays as a record.

Resolve a flag

Open the transaction and read the Policy flags section. Select Resolve when you corrected the underlying problem. Select Dismiss when the flag does not apply. Both actions remove the flag from the open list and keep it in the transaction record.

Coding on a transaction

The transaction detail sheet shows the coding surfaces together:

• Policy flags raised against the transaction
• Dimensions pickers for department, location, and class
• Accrual window
• Coding trail showing which rule set which field
• Comments for the discussion about it

Coding precedence

Three layers can set a coding field. They apply in one order:

1. Account default is the floor. It applies when nothing else claims the field.
2. Transaction rules outrank the account default.
3. A value that a person set by hand outranks both. No rule replaces it.

Set an account default from the bank account record. It applies categorySlug and glCode to that account's transactions.

Coding trail

The trail records the field, the value, and the rule that set it. It also records the rules that matched but did not win, with the reason:

Use the trail when a coded value is not the one you expected. It answers which rule to change.

Accruals

An accrual spreads one charge across the periods it covers. An annual invoice paid in January is not a January expense.

Set a start date and an end date. Eigenn splits the amount across the calendar months that the window touches, allocated by day count rather than by month, because months differ in length. The last period absorbs the rounding remainder, so the parts always add up to the original amount.

Clear both dates to remove the accrual.

Receipt verification

Eigenn checks whether an attached receipt matches the charge, rather than only recording that an attachment exists. The wrong receipt, a duplicate, or a receipt from another month all satisfy "has an attachment."

A receipt is verified when:

• the amount agrees within one cent, comparing magnitudes because a receipt does not carry the ledger's sign, and
• the date agrees within five days, or the merchant name agrees.

The amount must always agree. Requiring the date and the merchant to agree as well would reject too much: receipt dates lag the posting date, and merchant strings differ between the processor and the printed name.

A value that a person marked verified by hand is never overwritten by an automatic check. That is the point of a manual override.

Limits

• A policy sweep covers up to 2,000 transactions per run.
• A chart import that stops early archives no accounts on that run.
• A constraint applies to one target field. Restrict several fields with several constraints.
• Eigenn applies only the most specific matching constraint per field.
• Dimension pickers on a transaction cover department, location, and class. Vendor values exist for coding rules and imports.
• Coding settings are team-scoped. Confirm the active workspace before you edit.

Confirm the Result

• The chart of accounts holds every account that operators must post to.
• Each dimension value uses the same key as your accounting system.
• A test transaction that matches a constraint offers only the allowed values, and a save with a disallowed value is rejected.
• A test transaction that meets a policy condition shows the flag and its message.
• A transaction that no longer meets the condition shows no open flag after the next sweep.

Troubleshoot

The GL picker offers few accounts

The chart is empty or nearly empty. Import it from a connected provider, or add the accounts by hand. Without a chart, the picker can offer only codes already used on transactions.

There is no import button

The connected provider cannot list a chart of accounts. QuickBooks Online and Xero support the import. Add the accounts by hand for the other providers.

A constraint does not restrict the field

Confirm that the condition matches the transaction. Then check whether a more specific constraint on the same field won instead. Eigenn applies one constraint per field, not the combination.

A flag came back after I resolved it

Resolving a flag does not change the transaction. If the transaction still meets the policy condition, the next sweep can raise the flag again. Correct the underlying coding, or disable the policy.

A flag did not clear

Only open flags clear automatically. A flag that a person acknowledged, resolved, or dismissed stays in the record on purpose.

The accrual parts do not match the charge

The last period carries the rounding remainder, so the parts should add up exactly. If they do not, confirm that the start date is not after the end date. An invalid window produces no schedule.

Related Pages

• Transactions
• Transaction Categories and Rules
• Reconcile and Categorize Transactions
• Maintain Transaction Rules
• Settings Overview