Custom Fields

Every business has one or two things it needs on a bill that no accounting package thinks to ask for: the cost centre, the order reference the client insists on quoting, the internal approval number, the site the work was done at. Custom fields let you add those to your customer and vendor transactions properly — as their own field, with their own type — instead of burying them in the description and hoping someone searches for them later.

The part that makes them worth setting up: the AI can fill them in from the incoming document. Once you’ve told it where to look, an order reference printed in the corner of a supplier’s invoice arrives already in the field, on every bill, without anyone reading the PDF.

You’ll find them under System → Defaults → Custom Fields (requires the defaults permission).

Where custom fields appear — and where they don’t#

Worth knowing before you plan around them:

• They appear on the customer (AR) transaction and vendor (AP) transaction screens, in the Details tab, in their own Custom Fields card.
• They do not appear on sales invoices or vendor invoices — the itemised documents.
• They are not printed on the PDF your customer receives.
• You can filter and search by them on the AR and AP overviews, but they are not a column there and don’t come through in the Excel or PDF export.

So: custom fields are for information you want to record, route, and find — not for information you want to show a customer.

Defining a field#

The tab lists your fields with their Label, Key, Type, Forms and Status. Add Field creates one; the pencil on a row edits it. Everything on this tab saves itself as you go — the Save button at the bottom of Defaults isn’t involved and doesn’t appear.

Two choices you can’t undo#

Field Key and Type are permanent. The key is derived from the label as you type, but you can edit it before saving — after that it’s fixed, because changing it would orphan every value already recorded on past transactions. The same reasoning locks the type.

In practice: get the type right, and don’t worry much about the key. The label is what people read, and the label stays editable.

If the key is rejected as invalid, it’s usually because the name is one the system already uses for a built-in field — project, department, amount, notes, description and a few dozen others are reserved. Adjust the key (cost_project, say) and the label can still read “Project”.

How each type behaves#

• Text — a plain text box. With multiple values switched on, it becomes a chip entry: type a value, press Enter, repeat.
• Amount — a number, formatted Swiss-style as you leave the field.
• Date — the standard date field: dd.mm.yyyy with a calendar picker.
• Select — a dropdown of the options you define. With multiple values on, several can be picked at once.

Options are worth a moment’s thought: they’re what the AI is allowed to choose from, and matching is exact. Keep them short and canonical (CC-100, not Cost Centre 100 (Zürich)).

Deactivating instead of deleting#

Fields are never really deleted. Deactivate takes a field off the forms and out of the AI’s reach while leaving every value already recorded untouched; Reactivate brings it back. Two consequences worth knowing:

• Required to post is cleared when you deactivate, and reactivating does not restore it. Re-tick it if you still want it.
• A deactivated field’s key stays reserved forever. You can’t create a new field that reuses it — pick a different key, or reactivate the old one.

“Required to post” — what it actually means#

This one matters, because the obvious reading is wrong.

Required to post means a person filling in the form by hand must supply it. It does not mean the transaction can never exist without it. Transactions the AI creates from your inbox, and transactions created by bank import, are exempt by design — they post with the field empty. Approving those in bulk from a workstation posts them that way too.

That exemption is deliberate: a missing optional reference should never block a financial posting that’s otherwise correct and already approved. But it means you shouldn’t treat “Required to post” as a guarantee that the field is always populated. Use it to stop people forgetting; don’t build a process that assumes the data is always there.

If someone tries to post with it empty, neoo jumps them to the Details tab and names the fields that are missing.

Teaching the AI to fill the field#

This is where custom fields pay for themselves. When a document arrives in your inbox, the AI reads it and drafts the transaction — and if you’ve defined custom fields for that form, it tries to fill them too. The values arrive pre-filled on the draft, and whoever reviews it can correct anything before posting.

AI Instructions is how you tell it what to look for. The text you write is attached to the field’s label and handed to the AI as the field’s description, so the most useful way to think about it is: you’re finishing the sentence that starts with the label.

What the AI already knows#

You don’t need to tell it any of this — it’s supplied automatically, and repeating it only crowds out the useful part:

• The type. It knows the field is text, a number, a date, or a choice.
• The date format. It’s already told to return dates as YYYY-MM-DD.
• The options. For a Select field it receives your exact option list and is constrained to it.
• That multiple values are allowed, where you’ve enabled that.
• That it should skip the field if the document doesn’t have it. It’s told twice.

What’s worth writing#

The AI has the document in front of it. What it lacks is your context — what the thing is called, which of several candidates you mean, and what to do when the document is ambiguous. That’s what the instruction is for.

• Name the wording the document actually uses, especially in German or French: Look for "Kostenstelle" or "Cost Centre".
• Say where it sits, if that disambiguates: in the header block, above the line items.
• Give an example of the format: Format is P-12345.
• Rule out the wrong candidate. This is the highest-value thing you can write, because it’s the one thing nothing else tells it: Use the buyer's order number, not our own invoice number.
• For Select fields, explain how to choose rather than relisting the options: Pick DE for German-speaking cantons, FR for the Romandie.

What to avoid#

• Don’t specify a date format. The AI is already told to return YYYY-MM-DD, and that’s the only form the field accepts. Asking for dd.mm.yyyy makes the value fail to parse, and it lands empty with no error — the single most common way to break a working field.
• Don’t ask for currency symbols or thousands separators on an Amount field. It’s asked for a plain number; nudging it towards formatted text risks the value being misread.
• Don’t restate the type, the options, or that multiple values are allowed. All supplied already.
• Don’t say the field is mandatory. The AI isn’t told about “Required to post” and isn’t bound by it — all this does is pressure it into inventing a value.
• Don’t ask for a fallback like “write N/A if missing”. An empty field is honest and visible; N/A looks like data.
• Don’t write an essay. One or two precise sentences beat a paragraph.

A worked example#

Label: Project Number · Type: Text · Show on forms: Vendor Transaction

AI Instructions: The project reference the supplier prints in the header, usually labelled "Projekt-Nr." or "Objekt". Format is P-12345. Use the supplier's project reference, not our internal order number. If none is printed, omit it.

Every sentence there earns its place: the first names the document’s own wording, the second gives the shape, the third rules out the wrong candidate, the fourth prevents a guess.

When a value doesn’t come through#

If a field arrives empty when you expected a value, the usual causes, in order:

1. The instruction asked for a format the field can’t take — a date in anything but YYYY-MM-DD is discarded.
2. A Select value didn’t match an option exactly. Matching is case-sensitive: zürich will not match the option Zürich.
3. The field isn’t on that form. A field shown only on Customer Transaction is never offered to the AI on a vendor bill.
4. The document genuinely doesn’t say. The AI is told to omit rather than guess — which is the behaviour you want.

In every one of those cases the value is dropped quietly rather than raising an error, because a questionable optional field must never block a posting. So when tuning a field, check the drafted transaction rather than waiting for a warning.