How to book a Purchase Invoice Item against a Liability/Reserve Account?

[golden-ape]

Hi ERPNext Community!

I am setting up ERPNext for a German company and have run into a workflow roadblock regarding reserve bookings (Rückstellungen) across different fiscal years.

Accounting Scenario (SKR04): We frequently need to book a reserve in the current year for anticipated costs, and then book against that reserve in the following year when the actual invoice arrives.

For example, anticipating 1000 € in legal fees:

• Year 1 (Reserve creation):

  • Debit 6825 - Legal costs | Credit 3070 - Other reserves (1000 €)

• Year 2 (Invoice received & paid):

  • Debit 3070 - Other reserves | Credit 1080 - Bank (1000 €)

ERPNext Roadblock:

In Year 2, when the invoice actually arrives, I want to log it as a standard Purchase Invoice linked to the specific Supplier (the lawyer) and use a specific Item for their services.

To achieve the correct Year 2 journal entry, I need to set the Item’s expense account to 3070. However, because 3070 is a Liability account, ERPNext does not allow to set it (see screenshot below). The system strictly expects an Expense or Asset account for Items and restricts the use of Liability accounts.

My Question: Is there a way to safely overrule this account-type validation for specific edge cases? Alternatively, what is the best-practice, ERPNext-native workflow to clear a reserve (liability) account using a standard Supplier Purchase Invoice?

Thanks in advance for your help and insights!

German version:

Hallo ERPNext Community!

Ich richte momentan ERPNext für ein deutsches Unternehmen ein und bin auf ein Workflow-Problem im Zusammenhang mit Rückstellungen über den Jahreswechsel hinweg gestoßen.

Buchhaltungsszenario (SKR04):

Wir müssen häufig im laufenden Jahr eine Rückstellung für erwartete Kosten bilden und im Folgejahr gegen diese Rückstellung buchen, sobald die tatsächliche Rechnung eintrifft. Ein Standardfall eben.

Beispiel: Erwartete Rechtsberatungskosten in Höhe von 1000 €:

• Jahr 1 (Bildung der Rückstellung): Soll 6825 - Rechts- und Beratungskosten | Haben 3070 - Sonstige Rückstellungen (1000 €)

• Jahr 2 (Rechnung erhalten & bezahlt): Soll 3070 - Sonstige Rückstellungen | Haben 1080 - Bank (1000 €)

ERPNext Issue:

Im Jahr 2, wenn die Rechnung tatsächlich eintrifft, möchte ich sie als normale Einkaufsrechnung (Purchase Invoice) erfassen, die mit dem jeweiligen Lieferanten (Supplier / dem Anwalt) verknüpft ist, und einen spezifischen Artikel (Item) für dessen Dienstleistungen verwenden.

Um die korrekte Buchung im Jahr 2 zu erreichen, muss ich das Aufwandskonto (Expense Account) des Artikels auf 3070 setzen. Da 3070 jedoch ein Verbindlichkeitskonto (Liability) ist, lässt ERPNext diese Einstellung nicht zu (siehe Screenshot unten). Das System erwartet für Artikel strikt ein Aufwands- oder Anlagekonto (Expense/Asset Account) und verbietet die Nutzung von Verbindlichkeitskonten.

Meine Frage:

Gibt es eine Möglichkeit, diese Kontotyp-Validierung für solche speziellen Sonderfaelle sicher zu überschreiben? Alternativ: Was ist der Best-Practice bzw. ERPNext-native Workflow, um ein Rückstellungskonto über eine normale Lieferantenrechnung aufzulösen?

Vielen Dank im Voraus für eure Hilfe und Ideen!

[ahsantareen]

Hi @golden-ape

Item can be set with income and expense accounts only knowing the fact ERPs are itemised and produce item level reporting. Those expenses or incoming can be deferred to any other prepaid asset or unearned revenue accounts respectively using deferred functionality available on invoices level.

Payable accounts moves with vendors or employee in ERPNext as both parties are payable.

You should create two different services items and book them in purchase invoice.

[asieftejani]

Hi @ahsantareen

Please can you elaborate some more - we have an NGO and their donations are put as liability (debit cash and credit specific funds) so that we can track them and return unused funds to them. Therefore we are also facing this problem when we want to make payments from purchase invoice

I think the deferred functionality you mentioned is on the sales/revenue side

@golden-ape by the way this can also be an issue when making shareholder/bank/intercompany loan re-payments or any kind of liability/equity account payments

Thanks

[volkswagner]

As a work around you can create an asset account and use the negative balance to act as a liability.

[asieftejani]

@volkswagner

Yes that’s what we ended up doing… Just we have to export the balance sheet and reclassify it in excel

[golden-ape]

Thanks everyone for the replies and insights.

Unfortunately, these workarounds don’t quite fit our scenario. It would honestly make the most sense if the system simply allowed the selection of a liability account. Professional bookkeepers know what they are doing, and artificially restricting this just creates unnecessary friction for standard accounting processes.

@ahsantareen I have to agree with asieftejani here. The deferred accounting feature is built specifically for deferring revenue or expenses, not for clearing a predefined liability.

@volkswagner Thank you for the suggestion, but unfortunately, that approach goes against proper German accounting standards and would definitely be flagged by an auditor.

Does anyone else have another idea or a more native ERPNext workaround to handle this? Has anyone successfully used a custom script or a specific configuration to bypass this restriction “safely”?

[asieftejani]

@golden-ape

Final option - book the expense in the normal expense account then use a journal entry to clear the liability
An extra step but am sure that will be acceptable to german auditors

[volkswagner]

@golden-ape

I have no idea why German accounting would ever expect invoices to be charged against a liability.

I think you should be try to fix the problem being created when you book the expense in year one.

Why are you unable to create the invoice in year one?

Year one is when you should include the item with its associated expense account, not try to bend the system by assigning a liability to an item.

If you assign a liability to the item, what happens when the invoice and expense happen in the same year? Do you create a similar item and assign it to an expense? Now you need two items for the same expense.

[golden-ape]

@asieftejani Exactly, this is how we are currently handling it (booking the expense and then doing a manual Journal Entry). However, this extra step creates a lot of unnecessary friction and room for error, especially considering the only thing blocking the direct booking is a UI filter setting on the account selection.

@volkswagner To clarify, this isn’t bending the system; it is a strict requirement in accrual accounting, specifically under the German Commercial Code (HGB). We cannot create the invoice in Year 1 because the supplier (e.g., the lawyer or auditor) hasn’t actually issued it yet. However, because the service was rendered in Year 1, we are legally required to build a provision/reserve (Rückstellung) for the anticipated cost before closing the fiscal year.

Regarding your question about what happens if the invoice unexpectedly arrives in the same year: technically, it is the exact same case. Once a reserve is created, we have to book it out when the actual invoice arrives. Currently, this would also create two separate bookings (the Purchase Invoice plus a manual Journal Entry).

---

---

By any chance, are there any other users from Germany who have run into this exact Rückstellungen scenario? How did you solve it natively?

[Jatin_Banshpal]

Hi @golden-ape

I understand your query.

ERPNext only allows expense and income accounts to be used when creating a purchase or sales invoice.

However, as you mentioned, your Other Reserves account is a liability account. To overcome this problem, you can follow the steps below to configure your books the way you designed and achieve the accounting solution you require.

I have replicated this in my instance to give you a clear view, with screenshots attached:

Setup Part:

1. In the Chart of Accounts, create the Other Reserves account under Liabilities. Its Root Type will remain set to Liability. However, while setting up the account, set the Account Type as Expense Account.

   
   

2. Create an expense account for Legal Expenses the normal way.

   

3. Create an item for Legal Expenses the normal way.

   

Solution Part:

Now, if you create a purchase invoice with the item, ERPNext will allow you to select Other Reserves as the expense account.

Now your journal entry will be reflected as follows:

• Other Reserves a/c Debit: 1000

• Creditor/Payable a/c Credit: 1000

  

Then you can make a Payment Entry to pay the supplier, or you can click on the Is Paid checkbox to directly post the payment entry as well. The Journal Entry in this case will be reflected as:

• Other Reserves a/c Debit: 1000

• Cash/Bank a/c Credit: 1000

  

The Creditor/Payable a/c will be debited and credited with 1000, nullifying the overall effect.

Hope this helps you. Let me know if this works for you.

[volkswagner]

It seems what’s needed is for Purchase Order to act like Sales Order. If Purchase Order hit the general ledger as Sales Order does, you’d be able to book the expense against the Item, then later create Purchase invoice from the purchase Order. Perhaps this can be achieved via Server Script and Client Script from the Purchase Order to generate the ledger entry.

EDIT: maybe Purchase Receipt can also be customized.

From Gemini:

To handle the situation where a service is rendered in one closing period but the supplier invoice arrives in a different (later) period, you need to practice Accrual Basis Accounting.

If you do nothing, your expenses are recognized late, distorting your financial performance for both periods.

ERPNext offers two clean ways to book this expense immediately when the service is performed: The Native Automation Method and The Standard Accounting Method.

Method 1: The Native Automation (Provisional Accounting)

ERPNext has a setting specifically designed for this scenario called Provisional Accounting for Non-Stock Items.

How it works:

When this feature is enabled, you use a Purchase Receipt to log that the service has been performed. The system then automatically creates the accounting accrual entries for you.

The Setup & Flow:

1. Go to Accounts Settings and check the box for “Enable Provisional Accounting for Non-Stock Items”. This is actually located in Company settings >Stock & Manufacturing

2. Define a Default Provisional Expense Account (e.g., Expenses Accrued But Not Invoiced under Current Liabilities).

3. The Step-by-Step Flow:

**1.Create the Purchase Order:**Period 1.

Raise and submit the PO for your service item as usual.

**2.Submit a Purchase Receipt:**Period 1 (Service Rendered).

When the service is completed, create a Purchase Receipt from the PO. Even though there is no “physical stock,” submitting this document will automatically trigger the following GL entry:

• Debit: Your Service Expense Account (e.g., Consulting Fees)

• Credit: Expenses Accrued But Not Invoiced (Liability)

  Your expense is now safely booked in the correct period.

**3.Submit the Purchase Invoice:**Period 2 (Invoice Arrives).

When the actual bill arrives in the next period, create the Purchase Invoice and link it to that Purchase Receipt. ERPNext will automatically reverse the accrual:

• Debit: Expenses Accrued But Not Invoiced (Clears out the liability)

• Credit: Accounts Payable / Supplier (Creates final vendor liability)

Method 2: The Manual Journal Entry (The Accountant’s Choice)

If you prefer not to turn on global settings or don’t want to use Purchase Receipts for services, you can manually manage the timing gap via a Journal Entry at the end of the closing period.

The Flow:

1. At the end of Period 1 (Service Rendered): Create a Journal Entry to manually record the liability.

   • Debit: Your Service Expense Account

   • Credit: Accrued Expenses (Current Liability)

   Tip: In ERPNext, you can set the Credit row’s Party Type to “Supplier” and select the vendor. This keeps your accounting accurate without prematurely hitting the official Accounts Payable ledger.

2. In Period 2 (Invoice Arrives): Book the Purchase Invoice normally when it arrives. This will hit your Expense Account and Accounts Payable.

3. The Crucial Cleanup: Immediately create a second Journal Entry to reverse your Period 1 accrual so you don’t double-count the expense:

   • Debit: Accrued Expenses

   • Credit: Your Service Expense Account

[asieftejani]

@Jatin_Banshpal - your sollution looks very interesting. I am just worried if it will not effect any standard reports or ratios? can you mind checking pls

@volkswagner- Method 1 is a good suggestion by Gemini and in most cases it will work. However sometimes we must make estimates for the bill in the previous month (e.g. in our developing part of the world the electrcity bill has not been received yet for this month - snail mail) and these will not match the actuals. If the difference can be handled properly in the accounts it would be a perfect sollution. @golden-ape What do you think?

Edit - I tested it and the receipt was done properly (Dr exp and cr accruals) but when I tried to match the purchase invoice it again debited expenses (instead of accruals) and credited creditors. So probably there is a setting i missed or did not follow proper procedure

[Jatin_Banshpal]

Hi @asieftejani

That is a completely valid concern to have whenever you tweak account settings.

Rest assured, this is not a workaround or a hack - this is actually how ERPNext is designed to handle these specific scenarios. It will not affect your standard financial reports or accounting ratios at all.

The reason is simple: ERPNext relies strictly on the Root Type (Liability) to determine where the account sits on your Balance Sheet and how it calculates financial ratios.

The Account Type (Expense Account) is just a functional filter that tells the Purchase Invoice it to select this account.

I am using this exact method in my own live system, and all financial statements, balance sheets, and compliance reports are being generated perfectly. You can safely implement it without worrying about your data integrity

[sabgaby]

We had the same issue, and we just did a client script, since its only a filter that blocks liability accounts:

for the Item:

frappe.ui.form.on('Item', {
    onload: function(frm) {
        frm.set_query('expense_account', 'item_defaults', function(doc, cdt, cdn) {
            const row = locals[cdt][cdn];
            return {
                filters: {
                    'company': row.company,
                    'is_group': 0,
                    'disabled': 0
                }
            };
        });
    }
});

For the purchase invoice:

frappe.ui.form.on('Purchase Invoice', {
    onload: function(frm) {
        frm.set_query('expense_account', 'items', function(doc, cdt, cdn) {
            return {
                filters: {
                    'company': frm.doc.company,
                    'is_group': 0,
                    'disabled': 0
                }
            };
        });
    }
});

We wanted to add a filter to be only allowed for certain item groups or supplier groups, but haven’t gotten around to it

[OnX]

Hi @golden-ape

Changing the Account Type of a liability account to “Expense” or writing client scripts to bypass the dropdown filter are functional workarounds, but they can introduce audit trail issues under strict German GAAP (GoBD).

A completely standard, GAAP-compliant way to handle this without changing native ERPNext account types or writing code is using a Technical Clearing Account (Transit/Interim Account) under Expenses:

1. Setup: Keep the Other Reserves account classified purely as a Liability. Create an interim expense account called Reserves Clearing Account (under Expenses).

2. Purchase Invoice: Book the invoice normally using the service item, pointing the expense account to the Reserves Clearing Account. (This satisfies ERPNext’s item-to-expense validation naturally).

3. The Drawdown: Create a simple Journal Entry to clear the transit balance:

   • Debit: Other Reserves (Liability decreases)

   • Credit: Reserves Clearing Account (Clearing account resets to 0)

What do you think, Do you agree ? Thanks

[Jatin_Banshpal]

Hi @OnX

Thanks for the perspective.

However, looking at how ERPNext’s architecture interacts with GoBD requirements, handling it directly via the configuration adjustment (mentioned above) is actually a highly efficient approach. Here is why:

• Audit Trail Security: GoBD focuses heavily on data immutability and traceability. Because ERPNext locks the General Ledger entries completely upon submission and relies strictly on the Root Type for Balance Sheet positioning, your audit trail remains completely unbroken, transparent, and compliant.

• Eliminating Human Error: The clearing account method introduces a mandatory two-step process (the Purchase Invoice plus a secondary manual Journal Entry). In a busy, real-world accounting department, requiring a second manual step creates a high risk of someone forgetting to clear the transit account, leaving you with a messy reconciliation issue at month-end.

Both methods ultimately land the exact same numbers on the Balance Sheet, but utilizing the native invoice flow cuts out that extra manual layer of operational risk.

Appreciate the great discussion on this layout!

[golden-ape]

Sorry for taking quite some time to answer. There where a few urgent things to finish up!

@sabgaby We went with your solution. It has a almost no impact in terms of security/compliance but it fixes the main problem of being able to select the correct default account! It is also well explainable to potential auditors. Thank you very much for sharing.

@OnX You solution is also possible! I personally think that the custom scripts eliminates the repeated booking, that is why we went with the client script solution. However, in certain cases where you want to have the overview via the clearing account (or have the strict requirement of not using the client script) your solution would be the go to!

Thank you everyone for engaging and providing so many nice answers