Posting Keys in SAP: What Do 40, 50, 31 and 01 Mean?

Anyone entering a posting in SAP GUI sooner or later runs into a small field labelled PK. Two digits, nothing more. And yet this value decides whether a posting works at all, and whether the amount ends up on the correct side of the account.

In the SAP Fiori apps, the field has mostly disappeared. A simple debit/credit switch has taken its place. The concept has not been abolished, though — it has merely moved into the background: the system still sets the posting key, it just no longer asks you for it.

This article explains what a posting key controls, which keys you genuinely need day to day, and how to remember the logic behind them.

What a posting key controls

The posting key is a two-digit key that belongs to every single line item. It makes three determinations at once:

1. The account type — what kind of account the line item posts to: G/L account, customer, vendor, asset or material.
2. Debit or credit — which side of the account the amount sits on.
3. The field status of the additional data — which further fields in this line item are suppressed, optional or required.

The key carries two further indicators in the background. You will not see them on the entry screen, but you will notice them in reporting:

• whether the line item relates to a payment transaction — the basis for analysing payment behaviour and generating payment notices;
• whether the posting is sales-relevant, meaning it updates the transaction figures of the account.

The most important posting keys at a glance

Six keys, and most of your daily work is covered. 40 and 50 carry every manual G/L posting. 01 appears on the outgoing invoice to a customer, 31 on the incoming invoice from a vendor. 11 and 21 are the corresponding credit memos.

Once you realise that a credit memo is, in accounting terms, nothing other than the invoice with the sides swapped, you no longer need to memorise the counterparts individually. Three examples show how they work together.

Manual G/L posting: rent paid by bank transfer

Incoming invoice from a vendor

The credit line does not land on a freely chosen account. It is posted automatically to the general ledger via the vendor's reconciliation account. How that link works is explained in the article General Ledger, Subledger, Reconciliation Account.

Outgoing invoice to a customer

Where gross and net amounts sit in the document

The last two examples show a split that recurs on every taxable invoice:

• The subledger account — customer or vendor — carries the gross amount. That is what the customer pays, or what you owe the vendor.
• The expense or revenue account carries the net amount.
• The tax amount sits on a separate tax account — which is itself a G/L account.

That last point matters more than it looks: input tax and output tax accounts are G/L accounts. The common rule of thumb "subledger accounts gross, G/L accounts net" therefore falls short. What is actually true is that the gross amount is split across several G/L line items.

For everyday document checks, one useful control remains: the subledger line item must equal the sum of the net amount and the tax.

The system behind the numbers

SAP does not hand out posting keys at random. They are delivered in number blocks, one per account type.

This gives you a memory aid that holds in most cases: the credit key is the debit key plus ten. 01 becomes 11, 21 becomes 31, 40 becomes 50, 89 becomes 99. The asset keys 70 and 75 are the exception.

For assets, read 70 and 75 simply as asset debit and asset credit, not as acquisition and retirement. The reason: asset retirements with revenue are in practice partly posted with key 50 to dedicated G/L accounts that are linked to the asset. The equation "70 equals acquisition, 75 equals retirement" therefore does not hold.

For asset and material line items, the posting key alone is not enough. The transaction type for assets and the movement type for materials come on top. They describe the specific business transaction and influence both the subsequent posting and valuation logic and the way the transaction appears in reporting.

For postings that reach G/L accounts from materials management, additional key pairs exist, such as 80/90, 81/91, 83/93, 84/94, 85/95 and 86/96. In such integrated transactions the system uses these keys itself; as an FI user you will not normally need to enter them.

Good news: this knowledge travels with you

Posting keys — like document types — are defined at client level. They are therefore identical across all company codes. What you know about key 40 in one company code applies just as well in the next.

Beyond that, SAP recommends using the standard posting keys as delivered. The reason is technical: if keys are changed or newly defined, every table that refers to them has to be updated. Companies accordingly deviate only rarely. For you as a user this means the keys you learn here are the same in virtually every SAP system — including after a change of employer.

Why two keys are enough for G/L accounts

The imbalance in the overview is striking: customers and vendors each have around twenty keys, G/L accounts exactly two. Behind this lies a deliberate division of labour between two control instruments.

For G/L accounts, the field status group handles the differentiation. It sits in the company code segment of the G/L account master record and determines which fields are suppressed, optional or required when posting: a bank account needs no cost centre field, an expense account requires one. Because that distinction is already attached to the account, two keys suffice — one for debit, one for credit.

For customers and vendors, the situation is different. The business partner master record itself carries no field status group. When posting to a subledger account, SAP therefore draws on the field status group of the associated reconciliation account, where it is maintained. That settles the account-dependent control, but not the differentiation by business transaction: invoice, credit memo, payment, interest calculation and special G/L transactions each require different fields. It is precisely this transaction-dependent differentiation that the posting key handles. That is why there are so many of them.

When the two sources contradict each other

Because the field status group and the posting key both act on the same fields, SAP has to decide which specification wins. The order of priority is:

1. Suppress (highest priority)
2. Required entry
3. Optional entry (lowest priority)

So if a field is optional in one source and suppressed in the other, it disappears. If it is optional in one and required in the other, it becomes a required field.

Where the posting key still appears today

In SAP S/4HANA you will encounter the key in three places:

• In the complex posting screen — the app Create G/L Account Postings (transaction F-02) — you still enter it yourself.
• In the simplified Fiori apps such as Post General Journal Entries (F0718), a debit/credit switch replaces it. The key is set in the background.
• In the document display you see it in every line item — regardless of which app was used to post.

The last point is the most useful in practice: when you review someone else's document and want to know what actually happened, the posting key column often tells you more than the item text. Why the field disappeared in Fiori in the first place, and what that means for daily work, is discussed in the article SAP GUI vs. Fiori.

Common pitfalls

The key does not match the account. Anyone trying to post to a vendor with key 40 gets an error message. The key defines the account type, and the system checks against it consistently. The message looks cryptic but simply means: wrong account type for this key.

Gross and net get swapped. The gross amount belongs on the subledger line item, the net amount on the expense or revenue account, the tax on the tax account. Enter the tax twice and you end up with a document that will not balance.

Debit and credit get read as plus and minus. Debit and credit are neither a judgement nor a sign, but simply the left and the right side of an account. Whether a debit amount increases or decreases the balance depends solely on the account type.

The key is set automatically and searched for anyway. For automatically generated postings — payment run, goods receipt, depreciation run — the system determines the key itself. Trying to override it manually there means looking in the wrong place. Which postings SAP generates on its own is described in the article Why Does SAP Post Automatically?

Key takeaways

The posting key determines three things at once for every line item: the account type, the posting side and the field status of the additional data. Six keys cover the daily routine — 40 and 50 for G/L accounts, 01 and 11 for customers, 21 and 31 for vendors. For the standard pairs the credit key is usually ten numbers higher; the asset keys 70 and 75 fall outside that pattern.

Gross or net is decided by the business transaction, not by the key. Two keys suffice for G/L accounts because the field status group takes over the account-dependent control there; for subledger accounts the posting key differentiates by business transaction. And because the standard keys are in use unchanged in virtually every system, this knowledge transfers.

You will rarely see the key in the Fiori apps. You should still understand it — at the latest when you have to review someone else's document or make sense of an error message.