Posting keys control individual accounting line items; document types classify the accounting document as a whole. Learning that distinction makes supplier invoices easier to explain and posting errors easier to investigate. This guide uses a small, fictional invoice to connect the controls with the accounting result.
For learners comparing SAP FICO training in Vizag, this is a useful practice topic: explain the business event first, then show how document-level and line-item controls support it.
What is a posting key in SAP FI?
A posting key identifies the debit or credit side and the account type for a line item. It also contributes to the field-status controls used when entering the item. A document normally contains multiple line items, and those items can use different posting keys.
Standard examples commonly encountered in classic FI posting are 40 for a G/L debit, 50 for a G/L credit and 31 for a vendor credit. Treat these as standard learning examples, not instructions to change a configured system. Posting applications and automated processes may derive values rather than asking the user to enter them.
What is a document type?
A document type applies at document-header level. It classifies the transaction, controls which account types are permitted and is associated with a document number range. In a standard classic FI setup, KR is commonly used for a vendor invoice and SA for a G/L accounting document. A business can configure document types differently.
A document type does not replace the posting keys of its line items. Nor does a posting key decide the overall classification or numbering of the document. Read both controls before drawing a conclusion about an unfamiliar posting.
Posting key vs document type
| Question | Posting key | Document type |
|---|---|---|
| Where does it apply? | Individual line item | Document header |
| Does it distinguish debit and credit? | Yes | Does not determine every item’s debit or credit side |
| How does it relate to account types? | Specifies the item account type | Controls permitted account types for the document |
| How does it relate to fields? | Contributes to line-item field status | Has document-level controls; it is not a substitute for item field status |
| How does it relate to numbering? | Does not assign the document number range | Associated with a document number range |
Worked example: a supplier invoice for ₹10,000
Assume a fictional company receives a ₹10,000 invoice for an operating expense and posts it directly in FI. Exclude tax, withholding, discounts and currency conversion so the exercise isolates the basic accounting. A purchase-order-based invoice has additional MM integration and document-flow considerations; this example does not represent that complete process.
| Line item | Debit | Credit | Common standard posting key |
|---|---|---|---|
| Expense G/L account | ₹10,000 | — | 40 |
| Supplier account | — | ₹10,000 | 31 |
| Total | ₹10,000 | ₹10,000 | Balanced document |
In a conventional classic FI configuration, the header might use document type KR. The expense debit records the cost, while the supplier credit establishes the liability. The supplier’s reconciliation-account assignment connects the subledger posting with the general ledger; the learner should not add another ₹10,000 liability line simply to repeat that relationship.
The invoice creates an open supplier item. Paying it is a separate business event, and clearing depends on how the payment and open item are processed. For the wider flow, read the SAP FICO accounts payable guide.
Why can a balanced invoice still fail?
Balancing debit and credit is necessary, but it is not the only condition for posting. An expense may require a cost assignment, the posting period may be closed, the supplier may lack company-code data, or a required field may be missing.
For a G/L line, review the posting key’s field status alongside the field-status group assigned to the G/L account. They work together. A conflict such as one setting suppressing a field that another requires needs investigation; it cannot be explained away by saying the amounts balance. Other application and configuration controls may also affect entry.
- Read the exact error message. Record the affected account or item and distinguish a field-status problem from a period, master-data or authorisation issue.
- Confirm the business event. Check whether the intended transaction is a supplier invoice, credit memo, payment or G/L journal.
- Inspect the header. Review company code, dates, currency and document type against the intended posting.
- Inspect the items. Check account type, debit/credit direction, amounts, tax assumptions and required account assignments.
- Trace the governing setting. Compare the relevant field-status and master-data controls before proposing a correction.
- Retest the same case. In an authorised training or test environment, confirm both the posting result and the expected line-item report.
A practical exercise for your FICO portfolio
Write a one-page specification for the ₹10,000 invoice: company-code context, assumed currency, expense account, supplier, dates, account assignment and expected debit/credit entries. Use fictional master data supplied for your learning environment.
Then document three cases: a valid invoice; an invoice missing an account assignment required by that setup; and an invoice using a posting date in a closed period. For each, record the expected outcome, actual message and evidence used to explain the result. Do not change controls merely to make every case post successfully.
A useful portfolio shows reasoning, not only screenshots. It should explain why the invoice is a liability, which controls apply at header and item level, and how the observed result matches the test case. Extend the exercise with the Universal Journal learning guide when studying S/4HANA reporting.
Common questions
Is a posting key the same as a G/L account?
No. The account identifies where the accounting entry belongs. The posting key contributes to the item’s account type, debit/credit direction and field status.
Does KR apply to every supplier invoice?
No. KR is a common standard example for direct FI supplier invoices. Purchase-order-based invoice verification and customer-specific configurations can use other document types and processes.
Are these concepts relevant to S/4HANA?
Yes. Accounting-document controls still matter, although applications, Business Partner master data and reporting differ by edition and configuration. Confirm the training-system version before reproducing screen-specific steps.
Learn the process with guided practice
Softenant’s SAP FICO course in Visakhapatnam covers document controls, G/L, accounts payable, accounts receivable and integration scenarios. Review the syllabus and contact the team to confirm the current batch and practice arrangements.