Whenever there are lines in Business Central, there’s a very specific pattern applied because internals depends on it. In this video I give line numbers the ELI5 treatment. Check it out:
In this video, Erik explains a fundamental concept in Business Central (and its predecessors — Dynamics NAV, Navision, and Navigator) that often trips up developers coming from other platforms: how line numbers work on documents. Rather than incrementing by 1, Business Central uses increments of 10,000 — and there’s a very good reason for it.
The Question: Why Not Start at 1?
A recurring question from developers new to Business Central is about line numbering on documents — sales orders, purchase invoices, journals, and anything else that involves line entries. People coming from other platforms often assume line numbers should start at 0 or 1 and increment sequentially (1, 2, 3, …). While that seems to work, it can cause real problems down the road.
Understanding the Primary Key Structure
Erik demonstrates this using a Payment Journal in Business Central. Using the Page Inspector, he shows that the underlying table is General Journal Line (Table 81). Looking at the table’s key definition, we can see that the line number is the last field in the primary key, and it’s defined as an integer.
This is a critical detail. The system relies on the line number being an integer as the last field in the primary key to enable a special behavior controlled by a page property.
The AutoSplitKey Property
On the Payment Journal page (Page 256), there’s a property called AutoSplitKey set to true. This property is what drives the automatic line number assignment behavior. When the last field in the primary key is an integer and AutoSplitKey is enabled, Business Central automatically calculates line numbers when you insert new records.
How It Works in Practice
Erik walks through a live demonstration:
- He creates the first line in a payment journal — it gets line number 10,000.
- He creates a second line below it — it gets line number 20,000.
- Now he inserts a new line between the two using Alt+N — the system calculates the midpoint and assigns line number 15,000.
- Inserting another line between 10,000 and 15,000 yields 12,500.
- Continuing to insert between increasingly close line numbers produces: 11,250, then 10,625, then 10,312, then 10,156, then 10,078, then 10,039…
Each time, the system splits the difference between the two adjacent line numbers. Eventually, after inserting about thirteen lines into that same gap, Erik reaches a point where line numbers 10,001 and 10,002 are adjacent — and there’s no room left to insert another line between them.
The “Line Cannot Be Split” Error
At this point, attempting to insert another line produces the error:
“The line cannot be split.”
Erik notes that while this error is rarely seen in practice (because 10,000 gaps provide enormous room for insertions), it will happen if you use increments of 1. With sequential numbering, you have zero room to insert a line between any two existing lines.
Why This Matters for Posted Documents
You might think: “I’m creating all the lines at once on a sales order and then posting it, so who cares?” But consider what happens after posting. If someone needs to manually create a credit memo from a posted sales invoice and needs to edit, insert, or rearrange lines, they’ll immediately hit the “line cannot be split” error if the original document used increments of 1.
The 10,000 increment ensures that users always have room to insert lines between existing ones — even on copied or corrected documents.
The 10,000 Increment in Code
Looking at the source code of Table 81, the 10,000 increment is simply hard-coded. Erik points out that in highly-edited scenarios — where users are constantly inserting and rearranging lines — some implementations have increased the increment to 100,000 to provide even more room.
However, there’s an upper bound to consider: since the line number is a signed integer, the maximum value is approximately 2 billion. This means:
- With increments of 10,000, you can have roughly 200,000 lines on a document.
- With increments of 100,000, you can have roughly 20,000 lines.
- With increments of 1,000,000, you can have roughly 2,000 lines.
For most business scenarios, 10,000 is the sweet spot and matches what standard Business Central uses throughout the application.
The Takeaway
When you’re building your own extensions and creating documents with lines, always increment line numbers by 10,000. This ensures your code behaves consistently with the rest of Business Central and avoids the “line cannot be split” error that will inevitably frustrate users.
// Example: Assigning line numbers when creating document lines programmatically
LineNo := 0;
// For each line you want to insert:
LineNo += 10000;
MyDocumentLine."Line No." := LineNo;
MyDocumentLine.Insert(true);
If you’re inserting a line between two existing lines, let the AutoSplitKey mechanism handle it on pages, or calculate the midpoint yourself in code:
// Inserting between two existing lines
NewLineNo := (PreviousLineNo + NextLineNo) div 2;
// Make sure there's actually room
if (NewLineNo = PreviousLineNo) or (NewLineNo = NextLineNo) then
Error('There is no room to insert a line here.');
Summary
Line numbers in Business Central aren’t just sequential identifiers — they’re part of the primary key and are designed with gaps of 10,000 to allow for flexible line insertion. This design pattern has been in place for over 30 years, going back to Navigator. When building your own AL extensions, follow this convention: increment by 10,000, and your software will behave just like the rest of Business Central.
