Defaults, Keys, And Review

After the basic mapping rows are in place, the next step is to handle fixed values, cleanup rules, and final review.

Default values

Default values are useful when the same value should be used repeatedly.

The most reliable use today is a default-only header field created with Add Default Value Field.

Example:

• Destination field: location code
• Default value: MAIN
• Result: every imported document gets MAIN in that field

This is useful for:

• fixed location codes
• fixed responsibility or department values
• other header fields that should always be set to the same value

Fixed location code example

You want every imported document to use the same location.

Suggested setup:

• create a row with Add Default Value Field
• choose the location code field
• enter MAIN

This is better than trying to extract a value that never appears on the document.

Transformations

Use a transformation when the extracted value needs cleanup before it is written.

Typical examples:

• convert a date into the format Business Central expects
• clean up text casing
• remove unwanted characters
• look up a code from a name

Example:

• Extracted value: 04/15/26
• Transformation: date conversion
• Result: the system stores a proper date value

Use the transformation card to test the result on a sample value before relying on it. For the available transformation types, see Transformations.

Key fields

Key fields help the system identify an existing record when matching or updating.

Use a key field when a value should help locate the correct record instead of always creating a new one.

Examples:

• vendor number
• external document number
• invoice number

If you use more than one key field, lower Key Field Priority runs first.

Keep key setup simple. One or two strong identifiers are usually enough.

Review checklist

Before you finish, check each row for these points:

• The extracted field name matches real sample data.
• The destination table is correct.
• The destination field is correct.
• Header rows are not marked as line fields.
• Line rows point to the correct line table.
• Fixed values are set up as default-only rows when appropriate.
• Any transformation has been tested on real examples.

Common mistakes to avoid

• Do not trust auto-map without reviewing it. Similar field names can still map to the wrong destination.
• Do not use spaces in extracted field names. Keep them in the same format used by the extracted sample data.
• Do not make too many fields required. That creates avoidable import failures.
• Do not assume a default value will rescue a bad extracted mapping. Use default-only rows for fixed values.
• Do not expect Clear All Mappings to remove rows. It clears the destination table and destination field assignments, but the rows stay in place.

If something does not work

Check these items first:

• Was the document processed with this analyzer?
• Does the extracted field name match the sample data exactly?
• Is the row mapped to the correct table and field?
• Is a line field accidentally set up as a header field, or the other way around?
• Was the value transformed into something Business Central can accept?

Current limits worth knowing

Defaults are not fallback values

If you set both an extracted field name and a default value, the processor does not currently apply that default as a fallback when the extracted value is missing. In practice, treat defaults as fixed-value mappings, not as automatic fallback values for missing extracted data.

Default-only line mappings are not applied

Default-only line mappings are not applied during line processing. If you need a line value, it should come from extracted line data or from a different design approach.

Field names matter more than saved paths

The setup stores a field path, and mappings created from document review copy that path into the mapping row. However, the active mapping step matches extracted data by field name, not by saved path.

Validation and transformation parameter fields are not active here

Validation rules exist in the table design, but they are not currently enforced in the main field-mapping processor path. Transformation parameters are also stored on the mapping record, but the active transformation call uses the selected transformation code directly instead of passing mapping-level parameters through the processor path.