Platform & settings

Everything on this page lives under Settings, and it is the work an administrator does once so that everyone else’s day-to-day is shaped correctly: the reference lists documents pick from, the numbers documents are issued with, who has to approve what, and the extra fields and rules a particular business needs on top of the standard ones.

Settings holds eighteen screens. Nine of them are the bookkeeping masters described on other pages — tax codes and payment terms, exchange rates, price lists, fixed-asset types and the four accounting dimensions (cost center, department, branch, project). A tenth is Roles & permissions. The seven described below are the platform proper. The Settings menu also links out to the Activity Log, which lives at its own address.

That leaves one screen with no other home, so here it is in a sentence: Notifications sets an in-app and an email toggle per category (approvals, documents, payments, system, general) and an email-digest cadence — but only in-app notifications are delivered today, so the email switches record an intention rather than changing what arrives.

Common Masters

Common Masters is one screen for the shared reference data that does not deserve a module of its own. Rather than eleven near-identical little lists, there is one engine with eleven categories, all the same shape: a code, a name, an optional parent, a sort order and an active flag.

Category	Parent it sits under
Countries	—
States	a country
Cities	a state
Designations, Units of Measure, Document Types, Payment Methods, Categories, Statuses, Languages, Time Zones	— (flat)

The landing page shows every category as a card with its live “n of m active” count, and beneath them a second set of cards for the masters that do have their own richer screens — the chart of accounts, tax codes, payment terms, fiscal periods, exchange rates, price lists and the dimensions. Those are deliberately not duplicated here; the cards simply deep-link to the module that owns the data, so nothing has two homes and two lists can never disagree.

The parent chain is typed. A state must name a country, a city must name a state, and every other category must not name a parent at all. Picking a city’s country first narrows the state list for you, but the cascade is only a courtesy — the server re-checks the combination and refuses a city filed under a country outright. Because a child’s parent is always a different category, the chain cannot loop.

Codes are unique case-insensitively within a company and category: IN and in are the same country, and the second one is refused with a plain “A Country with code IN already exists”.

Nothing is deleted. There is no delete action, by design — a lookup someone once picked is part of history, and a document that carries it has to keep rendering it forever. Retiring a value means deactivating it, which only stops it being offered; reactivating is the mirror action. The list carries an “Updated” column and the edit dialog shows the full created/updated trail.

The 249 ISO 3166-1 countries are seeded for you and flagged as standard data (you can still rename one — a display name is your business). The other ten categories start empty on purpose: a wrong “standard” list of subdivisions is worse than no list at all.

Note

Common Masters is a managed reference library today, not yet a source that feeds the rest of the app. An item’s unit of measure is still a free-text box, the payment-method picker on a payment is a fixed built-in list, and the contact form has no country field. Curate these lists if you want them ready — but nothing outside this screen reads them yet.

Document numbering

Every document Accounts issues gets its number from one engine, and the format is yours to set. Settings → Auto-numbering shows a card per document type — invoices, bills, customer and vendor payments, journal entries, credit notes, expenses, vendor credits, purchase orders, retainer invoices, fixed assets, credit refunds, estimates and sales orders — each with four controls:

• Format — a template of literal text and tokens. {SEQ:5} is the running counter zero-padded to five digits ({SEQ} unpadded, or a run of zeros like {00000}); {YYYY}, {YY}, {MM}, {DD} and {Q} render the date the number is issued on. Exactly one sequence token is allowed.
• Reset period — never, yearly, monthly or daily.
• Start value — the first number of each period.
• Increment — the step between numbers.

So INV-{YYYY}-{SEQ:5} reset yearly gives INV-2026-00001, and starts over at INV-2027-00001 in January.

The date tokens read the clock at the moment a number is minted, not the date written on the document. An invoice you enter today but date to last December is still stamped with this year’s tokens, and takes this year’s counter — so back-dating a document does not back-date its number.

Two things make this safe to edit. First, the preview is the real thing: as you type, the card asks the server to render sample numbers, and the server runs the same engine that mints live numbers — what you see on the card is what a document will be stamped with. Second, an invalid template cannot be saved. A save is validated as a whole (not just the field you touched), and a reset period without a matching date token is rejected with the reason: a yearly reset needs a year token, or numbers will repeat next January. The Save button stays disabled while the format is invalid.

A type you have never edited runs on a built-in default (INV-00001, BILL-00001, and so on), shown on the card as Default. Changing a format never disturbs the counter, so numbering continues from where it was rather than restarting.

Caution

Start value only applies to the first number of a period. Once a counter is running, the next number is always the last one plus the increment — raising the start value mid-year does not jump the sequence. It takes effect at the next reset, or on a document type that has not issued anything yet.

One card, Debit note, is offered by the screen but is not used: Accounts does not issue debit notes, so editing it changes nothing.

Approval processes

An approval process says who has to sign off on what before it can go out. With an active process for a document type, the manual step that would release the document — an invoice DRAFT → SENT, a bill DRAFT → OPEN, a purchase order or expense to APPROVED — is refused until an approval request against that document has been approved. Approving the final step then advances the document (and posts its journal) in the same transaction, so approval and release are one atomic event rather than two things that can drift apart.

Settings → Approval processes is where you author them. A process names a document type, an optional entry condition, and one or more steps.

• Entry criteria are built with the same condition builder used for validation rules, and are evaluated against a flat snapshot of the document — its own columns, plus number and total_amount aliases, the contact’s details and any custom fields. Leave it empty and every document of that type needs approval. Set “total amount is greater than 50,000” and only those do; a document that falls outside is told so plainly and proceeds without a request rather than being silently auto-approved.
• Steps run in the order you arrange them. Each names an approver (a user, a role, or both) and a style: sequential (one approval finishes the step), parallel (a set number of approvals), or unanimous (every resolved approver must approve). Each step also chooses what a rejection means — stop the whole request, send it back to the submitter, or carry on to the next step anyway.
• Timeouts are optional per step: after so many hours, the step can auto-approve, auto-reject, or escalate to a named role, whose members are then added as approvers and notified.
• Approval limits are enforced per user on invoices, bills and expenses: an approver with a ceiling is refused above it, and an approver marked as not permitted for that document type is refused outright. Limits are checked against whoever is actually clicking, so a delegate approves under their own ceiling rather than the delegator’s, and rejection is never limit-gated. A user with no limits on file is unlimited — and note that there is no screen or API route for setting them, so they take effect only where they have been loaded into the database directly. Purchase orders carry no limit of their own, so any approver named on the step may approve one whatever its value.

Reassigning a request adds someone to the current step rather than replacing the original approvers, and recalling is the submitter’s own escape hatch. Deactivating a process is how you retire it; editing the steps of a process with open requests against them is refused until those requests are finished.

A few things are worth knowing before you sit down with this screen. It has not yet adopted the user and role directory the rest of the app uses, so approvers are named by UUID here — the screen offers you yourself in one click, and an existing step displays the resolved names, but adding a colleague means having their identifier to hand.

The object picker lists eleven document types, and only four of them — invoice, bill, purchase order and expense — are gated by what you author. Debit note and Amendment the server no longer accepts, so a process on either cannot be saved at all. On the other five — journal entries, credit notes, vendor credits, customer payments and vendor payments — a process saves and activates happily, but those documents carry no Submit for approval button and no step in their lifecycle consults the process, so authoring one changes nothing. Budget is not in the picker at all, and the database refuses it too, so a budget approval process cannot be created today — see budgets.

Note

The timeout sweep does not run itself. Accounts exposes it as an endpoint your scheduler calls periodically; it is idempotent and safe to run twice. Without a scheduler wired up, timeouts and escalations never fire — everything else about approvals works normally.

Workflows

Workflows are the “when this happens, do that” layer. Settings → Workflows composes one in a sentence: when a record is created (or updated, or a watched field changes) on this object, optionally if a condition holds, wait this long, then take this action. Behind that sentence the app writes a graph, which is what the engine actually walks — and an Advanced toggle lets you edit that graph directly for anything the composer cannot express (branching switches, loops, parallel branches, explicit error edges).

Triggers. Record-created workflows dispatch on all eight objects the picker offers: contacts, invoices, bills, expenses, items, customer payments, vendor payments and credit notes. Record-updated workflows cover five of them — contacts, invoices, bills, expenses and items. Field-changed workflows fire on contacts and invoices only, which is narrower than the hint in the dialog suggests; on the other objects a field-changed workflow can be saved and activated but will never run. Where it does run, it needs at least one watched field named, and fires once per watched field that genuinely differs.

Actions.

Action	What it does
Send a notification	Writes an in-app notification to the triggering user (or a named one)
Update a field	Writes a value into the record’s custom-field bag on contacts, invoices, bills, expenses and items
Call a webhook	POSTs the record and its context as JSON, with a five-second timeout
Send an email	Sends through the app’s email transport

The webhook action will only call a public address — an internal host or a cloud metadata endpoint is refused, because a workflow author is a tenant user, not an operator of your network. The step record keeps the HTTP status and the URL without its query string, so a token in a query parameter is never logged.

The email action deserves a plain word. The composer gives you a subject and a body but no recipient box, so an email action built there falls back to recording an in-app notification for the triggering user — nothing reaches an inbox. To actually send, use the Advanced graph editor and add a to address to the action node, and make sure your deployment has the email transport configured; unconfigured, it defaults to a driver that logs the message and delivers nothing.

Delays are minutes-granular in the composer. The engine checkpoints the run and resumes it later — but, like approval timeouts, resuming is a sweep your scheduler calls; without one, a delayed workflow waits forever at the delay.

Running and watching them. A new workflow is created as a draft and only dispatches once you activate it, but Run test works at any status: paste a record snapshot and the workflow runs against it immediately. That is a real run — notifications are written, fields are updated, webhooks are called — so test with that in mind. The history icon opens every recent execution with its status, duration and error, expandable to the individual steps with each one’s output. A failed step follows an explicit error branch if the graph has one, otherwise it either stops the run or carries on, depending on the node’s setting.

Custom fields

Accounts registers nine standard objects you can extend: contact, item, invoice, bill, customer payment, vendor payment, journal entry, GL account and bank account. Settings → Custom fields picks one and manages its fields — create, edit, move up and down to set the display order, deactivate, delete.

A field has a label (its API name is derived from it on create, and locked afterwards) and a type, and the type drives what else the dialog asks for: picklist values for a picklist, minimum and maximum for a number, an expression and return type for a formula. Across the board you can mark a field required, constrain it with a regular expression, and supply the message shown when it fails.

Those constraints are enforced on the server when a record is saved, on all nine objects, along with a number’s minimum and maximum and a picklist’s allowed values; formula fields are computed at the same moment. A change takes effect immediately — saving a field clears the runtime’s cached catalogue rather than waiting for it to expire.

The dialog also offers a Unique toggle and a Default value box. Both are stored with the field, but neither is acted on yet: nothing rejects a duplicate value, and nothing pre-fills the default.

Note

There is no data-entry control for a custom field yet. The web editors carefully carry a record’s existing custom-field values through a save so nothing is lost, and the API and the workflow “update a field” action can write them — but no form on any screen renders an input for one. Define fields today to shape validation, workflow conditions and API payloads; typing values in from a document form is still to come.

There is also no custom-object builder: the nine objects above are what custom fields and validation rules attach to.

Validation rules

A validation rule is a condition that blocks a save when it is true — the inversion catches people out, so read it as “refuse the record when…”. Each rule names an object, a condition, the message the user should see, and optionally the field to hang that message on.

Conditions are built with the shared condition builder, over a catalogue of the object’s standard columns plus its active custom fields, so a rule can reference either. Rules can be deactivated without deleting them, and, like custom fields, a change applies to the very next save.

Use them for the policies an accounting package cannot know: refuse an invoice over 100,000 without a purchase-order reference, refuse a contact with no tax registration number when the country is India.

Forms

The forms platform captures structured information from your own team — a fixed-asset intake sheet, an expense justification, a supplier onboarding questionnaire. Settings → Forms lists them with status, category and search filters; each row can be edited, previewed, published, unpublished, sent to its submissions, or deleted.

The editor has two tabs. Fields is the drag-and-drop designer — the same component the rest of the suite uses. Rules builds conditional behaviour (show this field only when that answer was given) on the same condition builder as validation rules. A preview dialog mounts the actual renderer on the live schema, so what you see while authoring is what a person filling it in sees. A form’s slug is fixed once created; everything else stays editable.

A form is created as a draft and must be published before it accepts anything — submitting to a draft is refused. Submissions are validated again on the server against the stored definition, and a failure comes back per field, landing on the offending field rather than as one lump message. A submission stores the answers exactly as they were given, so a form that changes later does not rewrite its own history; the submissions screen maps those stored answers back to the current schema’s labels, falling back to the raw field name for questions the form no longer asks. Editing a form does not create a new version of it, so an old submission is always read through the form as it stands today.

Forms are an internal surface: filling one requires signing in to Accounts. There is no public link to hand to a customer.

Connects to

• Roles & permissions — every screen here is gated on a read or write grant, and the Settings menu hides what your role cannot open.
• Expenses & purchase orders and receivables & payables — the document flows an approval process gates and a numbering format stamps.
• Finance operations — budget activation is routed through the approvals engine, but with no budget process creatable it is not gated today.
• Audit trail — changes to roles, approval processes, custom fields, validation rules, forms, numbering configuration and common masters are all recorded.