# Joining transactions
You will occassionally see the join-transactions-failed error. This guide provides more information on how this problem occurs and why it is unresolvable.
# Multi-row transactions
Often a transaction description may span multiple rows e.g.
- this transaction has a 1 row description
- this transaction has a 4 row description
# Top-aligned or Vertically-centered
Our parser can't see the lines (and not all statements have grid lines anyway) so we need to work out which description lines go with which transactions - e.g. in the previous picture transaction 1 could include just the first line (glass mtm salary) or two lines (glass mtm salary + speedpoint10025) or three lines (glass mtm salary + speedpoint10025 + 017fnb).
We use 2 algorithms based on two different layouts which statements use with multi-row transactions - i.e. either the date is on the first line (top-aligned) or the date is in the middle (Vertically-centered). Most statements use the top-aligned approach which is easy for us to handle, however a handful of statements use the Vertically-centered approach. We can handle centered lines however if there is ever an error with the statement and an extra line is added or the date is not centered on one or more of the multi-row transactions then we can't reliably determine which rows to group together. In this case we return the join-transactions-failed error.
# Both Top-aligned and Vertically centered in the same statement
Very rarely statements contain both top-aligned and Vertically-centered transactions. Unfortunately these transactions cant be reliably joined because a parser can only assume one of the two algorithm's at a time and cannot be programmatically determined on a per line basis, therefore changing which algorithm is used changes how all the transactions are joined in the entire statement, for example by assuming all transactions are top-aligned the vertically-centered transactions will be incorrectly joined with previous rows and by assuming all are Vertically-centered the top-aligned transactions will be incorrectly joined with previous rows.
# Example
In the example below the transaction at (1) is inconsistently positioned relative to the multi-row transactions - it should have appeared between: 017fnb and speedpoint10025. As a result all of the rows at (2) are incorrectly considered to be part of the transaction at (3):
# Why it is unresolvable
The error is unresolvable because there is no automated way to figure out where the extra row came from. If an extra row is added then it will cause the transaction below to take too many rows from the next transaction and the transaction below that to take too few. Where you see the error could be any number of transactions below the actual addition (it depends on the statement) so there's no way to figure out which prior transaction the row was added to.
It's also not possible to simply correct from the transaction where the break was detected onwards, because it's unclear how many rows that transaction should actually have. We could guess but we would be unclear how many rows had been offset into the incorrect transaction, and this may be difficult for a user to detect manually from our output.
For this reason we took the view that we should just return an error and alert the user rather than return dubious results.