---
title: "How does LUSID resolve transactions to transaction types?"
slug: "how-does-lusid-resolve-transactions-to-transaction-types"
tags: ["resolve transactions", "transaction types", "mapping"]
updated: 2024-08-20T13:42:47Z
published: 2024-08-20T13:42:47Z
canonical: "support.lusid.com/how-does-lusid-resolve-transactions-to-transaction-types"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://support.lusid.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How does LUSID resolve transactions to transaction types?

Every [transaction you upsert](/v1/docs/how-do-i-create-or-update-a-transaction) to a transaction portfolio LUSID must resolve to a known [transaction type](/v1/docs/what-is-a-transaction-type) in order to define the precise economic impact; that is, the effect on your holding in the underlying instrument, and also potentially on holdings in other instruments in the portfolio too (for example, currency holdings).

> **Note**: By default, LUSID operates a ‘data load first’ policy, so transactions are upserted and resolution failures must be handled manually as a post-process step. You can increase the level of validation to *reject* transactions that do not resolve to transaction types. [Find out more about this](/v1/docs/validating-transactions).

An upserted transaction:

- *Must* have its `type` field set, specifying the name of a transaction type.
- *Can* have its `source` field set, specifying a data provider for a set of transaction types.
- *Can* be in a parent portfolio that has its `transactionTypeScope` field set, specifying a logical repository of transaction types valid for this portfolio.

[Find out more about scopes and sources](/v1/docs/grouping-related-transaction-types-using-scopes-and-sources).

For each upserted transaction, LUSID examines the `type` field and performs the following steps in turn:

1. LUSID determines the transaction type scope in which to look. If the parent portfolio has a custom scope set, LUSID examines that scope. If not, LUSID examines the built-in `default` scope. Unlike when [resolving instruments](/v1/docs/how-does-lusid-resolve-data-to-instruments), LUSID does not ‘fall back’ from a custom transaction type scope to the `default` scope.
2. If a transaction has its `source` field set (for example, to `Goldman`) then LUSID searches the `Goldman` source in the given scope for a matching transaction type.
3. If no transaction type is found, LUSID searches the `default` source in the given scope for a matching transaction type.
4. If no transaction type is found and the transaction has a source of (for example) `Goldman`, LUSID searches the `Goldman` source in the given scope for a transaction type with `isDefault` set to `True`.
5. If no transaction type is found, or if the transaction has no source, LUSID searches the `default` source in the given scope for a transaction type with `isDefault` set to `True`.

If a transaction type *still* cannot be found:

- By default, the transaction is upserted into LUSID with metadata warnings, but excluded from holdings calculations. You should edit the `type` field of these transactions to supply a known transaction type.
- If you have [increased the level of validation](/v1/docs/validating-transactions#increasing-the-level-of-validation-to-reject-unresolved-transactions) to reject unresolved transactions, then the transaction is not upserted. You should specify a known transaction type in the API request before attempting to upsert again.

The following flow diagram summarises the mapping logic:

![](https://cdn.document360.io/d575ad81-c0ed-4980-bbd1-d59ac5c3de82/Images/Documentation/7cfc63a0-3044-441b-9c2a-1415d3c25006.png?sv=2026-02-06&spr=https&st=2026-11-04T02%3A00%3A44Z&se=2026-11-04T03%3A00%3A44Z&sr=c&sp=r&sig=Mw4omuXIfjvoL%2FBXtGNQk72eBZ9%2FHGk7nQyLnnWzkkQ%3D)