What's new – ERP

Anomalies, payment calendar and Mirakl tabs are labelled again (#3702)

The remaining ERP pages showed technical keys instead of readable text in 45 places: the bulk actions and the detail drawer of anomaly detection (detail.expectedValue, acknowledgeAll), the month navigation, the filters and the day tiles of the payment calendar (calendar.dailyInflow, calendar.weekTotal), the input fields of the Mirakl tabs for categories, messages, orders, promotions and shipments, the headings of three delete confirmations (account, sales channel, scenario), the cancel dialog for shipping labels, and the clean-up and product drawer of demand forecasting. What changes: All 45 places now carry a German and an English text. Fixed alongside: the weekday column headers of the payment calendar asked for calendar.weekday.mon while the catalogue has always carried calendar.weekdays.mon, so Mon to Sun were printed as raw keys.

Stock levels and cycle counts are labelled again (#3701)

In warehouse management, the Stock Levels and Cycle Counts tabs showed technical keys instead of readable text in 49 places - column headers read stockLevels.available, the button that posts an adjustment read stockLevels.submitAdjustment, and even the two tabs themselves carried tab.stockLevels and tab.cycleCounts. What changes: All 49 places now carry a German and an English text - column headers, filters, placeholders, the movement types (goods receipt, pick, put-away, adjustment, count, return, transfer), the stock status (low, OK, over), the count plan dialog and the replenishment table.

A note left while confirming or rejecting a withdrawal is now actually saved

The note field shown before confirming or rejecting a withdrawal declaration was accepted with no error, but silently discarded - it never reached the database, so it was gone the moment the action completed. It is now stored on the withdrawal record and available on lookup.

A returned SEPA direct debit now starts dunning (#3447)

If a bank returned a SEPA direct debit collection (for example, insufficient funds), the invoice it was collecting stayed marked as paid by mistake - nothing happened, and the outstanding amount was neither visible nor tracked. What changes: On a returned collection, the invoice goes back to open (unpaid, full amount), and - unless a dunning case is already running for it - a new dunning case starts automatically. A bounced payment no longer disappears from the books without a trace.

Credit notes now reduce the invoice's open balance (#3446)

A credit note linked to an invoice did not reduce the invoice's open amount - reports still showed the full invoice amount as outstanding, and dunning could chase the full (already partly credited) amount on an overdue invoice. What changes: Issuing a credit note, or cancelling one that was already issued, now adjusts the linked invoice's open balance accordingly - booked the same way a real payment is, so a later payment builds correctly on top of it instead of overwriting it. Drafts are left untouched; only issuing has an effect.

Dunning closes cases when the invoice is cancelled (#3443)

If an invoice with an open dunning case was cancelled, the case used to stay untouched - automated dunning kept sending reminders and could eventually escalate the case to an external collection agency, even though the underlying debt no longer existed. What changes: When an invoice is cancelled, the system now automatically closes every still-open dunning case for that invoice, noting "Invoice was cancelled". Cases already handed to collections, paid, or written off are left untouched - those continue as their own separate process.

Receiving stock now updates the stock shown in the shop (#3396)

When a purchase-order line item was marked fully received, or a goods receipt was accepted, only the internal erp stock used to increase - the stock the storefront and checkout actually read stayed unchanged. Newly received goods therefore kept showing as low or unavailable in the shop even though they were physically in stock; only a manual reconciliation run could fix the difference. The shop-facing stock is now updated automatically for every received quantity, with no manual step required.

Resuming a dunning case at the final escalation level now actually grants a grace period instead of immediate handover to collections (#3445)

Resuming a paused dunning case at the final dunning level promised a seven-day grace period with one more reminder - but did not deliver it: the next automated run instead handed the case straight to the external collection agency with no further warning. Resuming now correctly drops the escalation level back by one step, so the grace period triggers a regular reminder as promised before the case can escalate again.

Return requests in the storefront can be submitted successfully again (#3418)

The

Warehouse: manual stock correction now actually applies and is logged (#3394)

The manual correction on Warehouse > Stock Levels (the "Adjust stock" button) previously failed on every attempt without changing any stock. It now applies: the entered quantity change is applied to the real bin stock and logged in the movement history with the actual before/after values. When an article is stocked in more than one bin, the correction reports a clear message instead of guessing a bin - in that case, use the bin-level correction on the specific bin instead. A correction made directly on a bin's contents now also leaves an entry in the movement history.

Stocktaking, B2B registration decisions, receipt processing and customer invoice access work again (#3228)

Creating or updating a stocktaking count, approving or rejecting a B2B registration request, and verifying or booking a scanned receipt all failed with a server error on every attempt, so the record could never be saved. Customers viewing their invoice list or downloading an invoice PDF were always turned away as "not authenticated", even while correctly logged in. All four are fixed. Two smaller, related fixes: the natural-language query history now records who ran a query (the entry silently failed to save before), and accepting or rejecting a smart category suggestion now records the actual reviewer instead of always showing "system".

VAT management checks against VIES again (#2942)

The "VAT / VIES Management" page never showed any data, and the "Re-Validate", "Re-validate All" and "DAC7 Export" buttons did nothing - the underlying business function was missing entirely. What changes: The list now shows your suppliers with country, VAT ID, classification (EU B2B, EU B2C, UK, third country) and check status. A single check and a bulk check query the EU service VIES and write the result, with a timestamp, into the validation history. An outage is shown as an outage, not as "invalid": If VIES does not answer, or the member state stays silent, the last established status is left untouched and the history records "Not determined" together with the reason. A disruption at the checking service can therefore never mark a supplier invalid by mistake. Bulk check: A run checks up to 50 suppliers by default and then reports how many were checked, how many were valid, invalid or undetermined, and how many are still pending. One supplier failing does not end the run. DAC7: The export now produces a traceable report per calendar year, with period, generation time, the number of vendors covered and reportable, and the reported revenue. Past reports are in the new "DAC7 reports" tab. Maintaining tax data: The detail panel now lets you record the fiscal representative's VAT ID, the EU revenue and the deemed-supplier flag yourself.

The document archive checks retention and integrity for real again (#1496)

Four related

Every dropdown in ERP is now read out by name (#2859)

After the customer area and the HR area, ERP follows: anyone using it with a screen reader heard nothing but "combo box" in 46 places - with no hint of what was being selected. Almost every filter bar in the area was affected: bank accounts and bank transactions, cashflow with its payment calendar and scenarios, liquidity and bank reconciliation, journal entries and the DATEV export, sales channels, e-invoicing, receipt capture, anomaly detection, smart categorization, price recommendations, batches and serial numbers, stocktaking, wave picking, tiered pricing, location groups, routing rules, document sequences, document management with signatures, procurement with suppliers, supplier products and supplier invoices, purchase orders, quotes and shipping labels. All of them now carry a spoken name in German and English. Nothing changes visually, and mouse operation is unchanged. Banking · Procurement ·

Every dropdown in the warehouse tabs is now read out by name (#2859)

The filter bars of the three warehouse tabs were left out of the previous round, because they live in a different place technically than the rest of the ERP pages. They have now caught up: anyone using warehouse management with a screen reader heard nothing but "combo box" in 7 places - with no hint of what was being selected. Affected were bins with their zone and bin status, stock levels with stock status and movement type, and warehouse tasks with task type, status and priority. All of them now carry a spoken name in German and English, and where several dropdowns sit side by side the names are deliberately distinguishable instead of saying the same thing three times. Nothing changes visually, and mouse operation is unchanged.

lexoffice sync no longer shows fabricated results

Invoice, customer, and credit note sync, as well as batch sync, used to report a fabricated "synced successfully" confirmation with a fabricated lexoffice ID (lexinv..., lexcon..., lexcn...) for every transfer, even though not a single HTTP call was made to the lexoffice API. Batch sync also reported a fabricated success count. This was the same class of bug as the already-fixed connection check (see the 2026-08-17 entry) - carrying extra risk for an accounting integration, in case someone relied on a supposedly successful invoice transfer. All four features now show only the honest notice that sync is not available yet; the count of orders found during batch sync remains a real measurement, but none of them are reported as transferred.

Purchase orders now announce themselves for approval

Until now a submitted order sat quietly at Pending approval until somebody looked into the list of their own accord. From now on it appears as a process in the responsible person's worklist, with the order number and the supplier. Responsible is the supervisor of whoever submitted it - derived through the user account, the personnel record and the management line - and only if they hold the approve purchase orders permission. If that chain cannot be closed, a defect is recorded and nobody is notified; there is deliberately no round-robin mail to everyone who may approve. The process disappears by itself as soon as the order leaves that status, no matter who approved, rejected or cancelled it. The first run also picks up the orders that were already waiting. The notice deliberately names no amount: it would stand still while the order changes.

The last dropdowns in ERP are now read out by name (#2859)

This step completes the area. Caught up are the filters and forms that sat outside the warehouse tabs: invoices, credit notes, customer segments, fulfillment, locations, inventory with product stock and stock history, VAT management, dunning with its sort order, and returns with reason and item condition. Anyone using them with a screen reader heard nothing but "combo box" there - with no hint of what was being selected. All of them now carry a spoken name in German and English. Nothing changes visually. Invoices · Inventory ·

"Add line item" on a purchase order works again (#2836)

On the detail view of a draft purchase order, "Add line item" never created a line. The product name you typed was not sent at all, and the order was given an empty product reference - every attempt ended in a generic error message without saving anything. The form now offers the same product search as creating a new purchase order: you pick the product from the catalog, name and SKU are taken over, and the unit price is prefilled from the catalog price. As long as no product is selected, the button stays inactive.

A direct debit return is only receipted once it has actually been booked (#2820)

Reporting a return for a collection that did not exist - a typo in the reference, a collection belonging to a different merchant, an id from an old list - still produced the message that the return had been booked. Nothing appeared in the direct-debit overview afterwards, dunning never started, and nobody had a reason to look. From now on the call answers "not found" in that situation, before anything counts as done. The regular path is unchanged: a return for an existing collection is booked with its reason as before and shows up in the overview immediately. The same check now also applies where a merchant attaches evidence to a dispute - a dispute that does not exist answers "not found" instead of a system error.

A goods receipt is now created completely or not at all (#2834)

When an item failed while a goods receipt was being recorded, the interface reported an error - but the goods receipt header had already been written. What stayed behind was a goods receipt without a single item, holding a used-up document number from the WE- range. It counted in reports, it showed up in lists, and nobody could tell it apart from a real receipt - even though no goods had arrived at all. Document number, header and items are now written together: if anything goes wrong, no goods receipt is created and the number stays available. The same applies to changing the status of a goods receipt and to adding a single item afterwards. On top of that, invalid unit costs are now rejected with a clear message instead of ending in a server error.

A purchase order is now created completely or not at all (#2816)

When a line failed while a purchase order was being created, the interface reported an error - but the order header had already been written. What stayed behind was a purchase order without a single line, worth 0, holding a purchase order number that was used up. It counted in reports, it showed up in lists, and nobody could tell it apart from a real order. Header, lines and totals are now written together: if anything goes wrong, no purchase order is created at all and the number stays available. The same applies to duplicating an order, deleting a draft, approving and rejecting, and recording received quantities. On top of that, every purchase order line now needs a product from the catalogue; without one the input is rejected with a clear message instead of ending in a server error.

Accounting reports now stay inside one chart of accounts (#2839)

If you keep several charts of accounts side by side, SKR03 and SKR04 for instance, the same account number was allowed to appear in each of them - and the reports did not tell them apart. The trial balance listed the accounts of every chart in one report, and for a number that exists in more than one chart the name and the account type came from an arbitrary one. In the account ledger that weighed heavier: the account type decides whether a balance is read as a debit or a credit balance, so the sign turned around as soon as the type came out of the wrong chart. Both reports now answer for exactly one chart. You can name it; if you do not, the first chart you actually keep applies. Movements that are already booked are still shown in full, even when their number is not in the chosen chart - a report that silently hides a booking would be the worse mistake. Also fixed: an unused account could not be deleted as soon as some other chart of accounts had bookings under the same number. The lock now protects the account in question instead of the bare number; it still holds where the bookings cannot be attributed to one chart beyond doubt.

All nine reference types usable for journal entries (#2817)

A journal entry could only point at a customer order, an invoice, a refund or a manual booking. Linking it to a supplier invoice, a purchase order, a credit note or a dunning notice instead ended in a server error on save and no entry was created - exactly the four links the reference type exists for. All nine types are now stored, and together with the year-end closing they are also offered in the filter above the list and in the selection when creating an entry by hand.

An aborted supplier creation no longer uses up numbers (#2846)

When a supplier was created, the supplier number (LIF-…) and the creditor number (K-…) were drawn before the supplier itself was written, and each of the three steps ran on its own. If the write failed, both numbers were used up anyway: the numbering was left with a gap that afterwards could not be told apart from a deleted supplier. For accounting that is a real difference, because a gap in the creditor range has to be explainable. Drawing the numbers and creating the supplier now happen in one go: if the creation is aborted, both counters stand exactly where they stood before. The same applies when creditor data is added to an existing supplier. Also fixed: if two people created a supplier at the same time, both could be handed the same LIF- number; the second creation then ran into an error message although nothing was wrong with it. Simultaneous creations now receive different numbers.

Journal lines stay within one chart of accounts (#2818)

If you keep several charts of accounts side by side (say SKR03 next to SKR42), a journal entry could be booked against an account number that only one of the other charts carries. The entry was accepted, and the account name of that foreign chart was written into the journal line - afterwards nothing in the ledger showed that something was off. A journal entry now belongs to exactly one chart: lines that do not add up within a single chart are rejected with an error message, and the account name always comes from the chart the entry is booked in. Existing entries are left untouched. Journal entries ·

Missing default data now reaches partly set-up tenants as well (#2847)

If you had already created an account or a language of your own in a new tenant before the default data ran through for the first time, the rest of it never arrived: one single entry of your own permanently locked out the full chart of accounts, the language list and the booking languages, without any notice. From now on each group is looked at on its own. Whatever is missing entirely is filled in; whatever you removed yourself stays removed and is instead reported in the operations log as incomplete, rather than passing silently as "all fine".

Purchase order matching in receipt capture finds orders again (#2832)

The "Match purchase order" button reported no matching order for every receipt and added a note claiming the purchase order module was not available yet. Neither was true: the search read two fields of the purchase order that never existed, and the resulting database error was turned into an empty result list. The match now searches by the supplier on file, returns results again, and shows each order with its supplier name and total. A genuine failure is no longer presented as "no matches" but reported as an error.

Purchase-order overview metrics show the real numbers again

The tiles above the purchase-order

Stock levels, batches and serial numbers are reachable again (#2837)

The stock list of a location, the low-stock list, the stock movements and both the batch and the serial-number views ended in a server error instead of showing your data - in every workspace. The cause was a query reading the product name from a field the database never had. It now reads the maintained product name of the respective language: preferably in your workspace's default language, otherwise from another maintained language, and if an article has no maintained name at all, its article number stands in the label - never an empty field. Searching the stock list of a location now matches exactly the label the list displays. This is the same rule the warehouse, the stocktaking and the shop's cart already use to label their positions.

Stocktaking and inventory valuation are reachable again (#2831)

Opening a stocktaking, starting it, completing it, reading its report and calling up the inventory valuation ended in a server error instead of the data - in every workspace. The cause was a query reading the product name from a field the database never had. It now reads it from the maintained product name of the respective language: preferably in your workspace's default language, otherwise from another maintained language, and if an article has no maintained name at all, its article number appears in the label - never an empty field. The position list of a stocktaking is therefore sorted alphabetically by that label again. This is the same rule the warehouse and the storefront cart use to label their positions.

Suppliers and creditor data can be created, opened and edited again (#2868)

Supplier management was entirely unusable. The supplier list would not load, a single supplier could not be opened, and every attempt to create or change a supplier ended in an error message. The same applied to the "Creditor" tab with its bookkeeping details such as creditor number, payment method, early-payment discount, credit limit, dunning block and delivery terms: nothing could be saved there, because the database had never been given room for those details. The room is there now, and the creditor number is assigned automatically again when a supplier is created. Also fixed: entries the form explicitly allows were rejected by the database. This affected long VAT identification numbers, long city and region names and phone numbers at the length limit; bank details and tax numbers could not be stored at all, because both are kept encrypted and encrypted values need more room. All of it fits now. Supplier data already stored is unchanged and needs no rework.

The SEPA batch run can no longer leave a half state behind (#2821)

When a batch file was generated, the named collections were first marked as "submitted" and the batch file was written only afterwards. If that second step failed, the collections stood in the books as if they were at the bank - although no file had ever been produced. A second attempt did nothing, because it only picks up open collections. What changes: the status change and the batch file are now created together or not at all. If anything fails, the collections stay open and can be submitted again straight away. What you see in the overview: the reported number, and the number of transactions in the PAIN.008 file, now name the collections that really went into the run rather than the number requested. Naming a collection that has already been submitted no longer produces a file claiming more transactions than it carries. Existing cases: collections left stuck on "submitted" by the old defect are set back to "open" automatically at the next service start - they are recognised by the fact that no batch file exists for their batch reference. Collections with a real batch file are left untouched.

Warehouse tasks, barcode scanning and the goods receipts are reachable again (#2823)

Opening a warehouse task, the task list, the barcode scan, the contents of a bin, a goods receipt, a packing station and a return receipt answered with a server error instead of their data - in every workspace. The cause was a query that read the product name from a field the database never had. It now reads it from the maintained product name of the respective language: preferably in your workspace's default language, otherwise from another maintained language, and when an article has no maintained name at all, its product number becomes the label - never an empty field. This is the same rule the shop cart uses to label its lines.

Tab strips in ERP views unified and keyboard operable (#2023)

Twenty ERP views used to draw their own tab strip - Banking, Liquidity, Cashflow, Warehouse, Wave Picking, Procurement, Shipping Carriers, Document Management, DATEV Export, E-Invoicing, Lexoffice, Channels, Anomaly Detection, Demand Forecasting, Price Recommendations, Receipt Capture, Smart Categorization, quote details and location details. They now all use the same interface building block. What visibly changes: spacing and the blue tone of the open tab are identical across all views from now on, which makes some strips slightly more compact than before. The tabs themselves, their order, their labels and their content are unchanged. What is new: the strips can be operated entirely from the keyboard (arrow keys, Home, End), screen readers announce them correctly as a tab strip, and a strip with many tabs now scrolls sideways instead of cutting labels off.

Acknowledging and resolving now carry your name (#2540)

Who acknowledged a liquidity alert, who resolved an anomaly alert and who changed a marketplace commission rule used to be taken from the caller's request instead of from the signed-in session. Any caller could therefore have an arbitrary other name recorded, and the audit trail then carried the forgery as truth. All three are now taken from your sign-in without exception. Also fixed: the "Acknowledge" button on a liquidity alert did not work at all - it sent no name, which the endpoint insisted on, so it ran into an error message. It now acknowledges the alert and records you as the acknowledging person.

Filters in the stock history are now checked (#2356)

The stock adjustment history allowed filtering by product, location and adjustment type without checking the values. A malformed product or location id caused a server error, and an unknown adjustment type was silently ignored - the list came back unfiltered while looking filtered. Both are now rejected with a proper error message.

List pages across ERP now honor the selected page size

Lists such as Dunning,

"Send invoice" on draft orders now asks first - and names the recipient

Under ERP › Draft orders, the paper-plane icon in the row mailed the invoice straight to the customer with no question asked. It was the only action on that screen whose effect leaves the house - "Convert to order" and "Delete" right next to it had been asking all along. A confirmation window now names the recipient address; only the second click sends. A sent invoice cannot be recalled. Also new: under ERP › Transfers, removing a line item from a saved transfer now asks, because the expected and received quantities booked against it disappear with the row; and under ERP › Tax rules, removing a tax registration now asks, because its registration date and threshold for that jurisdiction go with it. Line items of an unsaved draft are still removed without a question.

Deleting a draft order now demands the "Delete orders" permission (#2222)

Permanently deleting a draft order rode along on the Edit orders permission, although the permission editor offers a dedicated Delete orders permission that nobody ever checked. The delete permission now counts. Of the shipped roles, super administrator and administrator delete; an editor still creates, changes, cancels and converts drafts - only the permanent delete is out of reach.

The "Export analytics" permission now genuinely governs only the CSV download

The report export under Reports → Export CSV used to check the general read permission for analytics, not the dedicated export permission built for it - a role with the read permission but not the export permission could still download CSV files. Nothing changes for the shipped roles: the export permission is still automatically derived from the analytics read permission. You will only notice this on a custom-built role or permission override that deliberately took the export permission away - that revocation now actually takes effect.

The dunning run can be started again by the role that owns it (#2219)

The Start dunning run button demanded an operator-plane permission behind the scenes, although the run only ever processes your own dunning cases. Since the permission change of 21 Aug no tenant role carries such a permission any more - a click therefore ended in a generic failure message, even for accounts that may otherwise send reminders, pause cases and write them off. The only accounts still getting through were Owner and Super Administrator, because those bypass the permission check altogether. The same bar as for every other dunning action now applies: Edit payments. Nothing about the run itself changes, and the hourly automatic check kept running regardless.

The granular ERP permissions now actually take effect (#2220)

Under ERP the permission matrix has always offered a separate permission per area - warehouse, stocktaking, picking, inventory, purchase orders and dunning, each for reading and for editing. Granting or revoking them changed nothing so far: the pages only ever checked the coarse umbrella permissions above them. A role given nothing but "Edit warehouse" hit an error on its first click, and revoking "Read picking" locked nobody out. Twelve of those permissions are now checked on the pages they belong to. Nobody loses access - the previous umbrella permissions keep working and open exactly the same pages as before. What is new is that you can genuinely limit a role to a single ERP area. For Invoices, Accounting and Cashflow things stay as they are for now; since the permission change of 23 Aug those pages are reserved for the Super Administrator, and the menu entries now say so correctly instead of leading to an error message.

Sending an invoice is now a permission of its own - and a second click does not send it twice

Until now a single permission ("Edit invoices") opened both: changing the draft and mailing the finished invoice to the customer. Sending now has its own permission, Send invoices; the edit permission alone is no longer enough. Roles that could send before still can - the new permission was handed to them automatically. What is new is that you can take sending away on its own, without taking editing with it. On top of that, send, finalize, record payment and refund a credit note now carry a repeat marker: if the same operation is submitted a second time - double click, dropped connection, another attempt - the system answers with the result of the first attempt instead of repeating the action. One mail goes out instead of two, an invoice number is drawn once, and a payment is booked once.

Stock reconciliation: warehouse stock and sellable stock are now checked against each other regularly

The warehouse stock from inventory management and the sellable stock on the product are kept separately - which is why they can drift apart, for instance when a stock booking is lost in transit or an outgoing movement was stopped at zero. Until now that only came to light when somebody looked. Under Warehouse → Stock reconciliation a regular pass now reports every deviation, lists it per product with both figures side by side, and notifies you when it finds one. The automatic pass only reports and changes nothing. A correction is something you start deliberately; it pulls the sellable stock up to the leading warehouse stock - and only where the deviation is unambiguous. Three cases are deliberately left untouched and merely reported: a stock booking still in transit, a product without any location record, and warehouse stock for a product the shop does not know.

Calendar dates in finance and operations no longer convert to world time

the invoice date and due date of the electronic invoice (ZUGFeRD/XRechnung), the month buckets of the liquidity forecast, the periods of the warehouse KPIs, the 30-day revenue curve, the due list in cash flow, the thresholds of the liquidity alerts and the default periods of the reports used to be cut out of world time (UTC). Between midnight and 02:00 German time that was the previous day, with three concrete consequences: an invoice created at 00:30 carried yesterday's invoice date (at the turn of a month or year, in the wrong VAT period), every month bucket of the liquidity forecast started on the last day of the previous month, and in the 30-day revenue curve the bar for the current day stayed permanently at zero because its key never matched the database's. On the warehouse cards, "last 7 days" and "completed today" contradicted each other. All of these now come from the tenant's time zone (Settings > Time zone). Document numbers, export file names and values that come straight out of a date column deliberately stay in world time. Nothing is rewritten retroactively - documents already produced stay as they are.

ERP operations now ask before something becomes final

Eight actions in the warehouse, stocktaking, receipt capture, liquidity planning, document management and quotes used to fire on the first click. Affected were: cancel a warehouse task, cancel a running stocktaking (throws away every quantity counted so far), extract a receipt and reject a receipt in receipt capture, delete an alert rule in liquidity planning, delete a document and delete a retention policy in document management, and delete a comment on a quote. Each of these now shows a prompt naming what is affected - the task with its product, the stocktaking with its name, the receipt with its document number, the rule and the document with their names, the comment with its author and the beginning of its text. Uploading a receipt deliberately gets no prompt: there you fill in a form, and its "Create" button is the prompt - it now also responds to the Enter key, which it did not before.

Field captions in draft orders, dunning and inventory are now linked to their field

In the draft orders (address, create customer, create draft and detail page), in dunning (create and detail view) and in the inventory (stock adjustment, inventory list, product view, transfer) the input fields carried a caption above them that was not technically linked to the field. That had two noticeable consequences: clicking the caption did not put the cursor in the field, and a screen reader announced the field without a name - you heard "edit box" instead of "Subject, edit box". That link is now in place. Nothing changes visually - captions, spacing, colours and field sizes are unchanged. One place sounds different: above the adjustment mode in the stock adjustment there is no input field but a row of choice buttons. A screen reader now announces it as a group with that name.

Field captions in ERP are now linked to their field

Across the ERP pages - balance sheet, profit and loss, journal entries, DATEV export, e-invoicing, liquidity planning, cashflow, scenarios, banking with accounts, import and reconciliation, receipt capture, lexoffice, purchase orders and supplier invoices, quotes, tiered pricing, price recommendations, batch and serial tracking, stocktaking, demand forecasting, anomaly detection, smart categorisation, routing rules, wave picking, locations and location groups, shipping carriers and document management - and in the warehouse area (stock levels, bins, receiving, pack station, returns, warehouse tasks, cycle counting, analytics and location details), the input fields carried a caption above them that was not technically linked to the field. That had two noticeable consequences: clicking the caption did not put the cursor in the field, and a screen reader announced the field without a name. 252 fields now carry that link. Nothing changes visually - captions, spacing, colours and field sizes are unchanged. Twelve places sound different: where what follows the caption is a group of several controls - the entry type and the recurring-rule type in cashflow, the scenario type, the stocktaking type, the picking strategy, the import format and the drop zone in the banking import, the data sources of smart categorisation, the discount field of a purchase order, the customer picker in a quote, and a shipping carrier's credentials - a screen reader now announces a group with that name instead of reading out a caption with no field behind it.

Field captions in ERP are now linked to their field

On the B2B companies, invoices, credit notes, returns, transfers, locations, customer segments, payment dashboard, import / export, global tax rules, export controls and sanctions and vendor KYC screening pages, the input fields carried a caption above them that was not technically linked to the field. That had two noticeable consequences: clicking the caption did not put the cursor in the field, and a screen reader announced the field without a name - you heard "edit box" instead of "Company name, edit box". 89 captions now carry that link. Nothing changes visually - captions, spacing, colours and field sizes are unchanged. Four places sound different: there the caption does not sit above a single input field but above a group of several controls - the colour swatches of a customer segment, the line items of a credit note, the export format picker, and the payout schedule in the payment dashboard. A screen reader now announces a group with that name.

Field captions in invoice creation are now linked to their field

In the Create invoice drawer (customer search, invoice recipient, line items, tax scenario, payment term, notes) and in the Record payment dialog under Invoices, the input fields carried a caption above them that was not technically linked to the field. That had two noticeable consequences: clicking the caption did not put the cursor in the field, and a screen reader announced the field without a name. That is fixed. Nothing changes visually - captions, spacing, colours and field sizes are unchanged.

Invoicing now asks before money or a document leaves the house

Ten actions in invoicing used to fire on the first click - no prompt, no way back. Affected were: issue a credit note (draws the final document number), refund a credit note (moves real money back), mark an invoice paid, finalize an invoice (draws the final invoice number), send invoice on a draft order (mails the invoice to the customer), send reminder in the dunning case list and in the case detail, capture payment, and remove a line item from an order. Each of these now shows a prompt that names the consequence - with document number, amount and, where something goes outside, the recipient address. "Capture payment" and the payout settings deliberately get no extra dialog: there you have already filled in fields, and the send button of that dialog is the prompt - it now also responds to the Enter key.

ERP, warehouse, dunning and draft-order areas moved to the shared interface controls (technical)

In the ERP sub-areas (accounting, procurement, goods receipt, banking, the Mirakl connection, quotes, document management, shipping carriers), in inventory, dunning, draft orders and the invoice dialogs, buttons as well as text, choice and multi-line fields now come from the shared interface toolkit instead of each page carrying its own code. Look and handling stay the same; what becomes consistent is keyboard focus, contrast in dark appearance and the behaviour of disabled fields. The tables in these areas have not been moved yet and will follow later.

Stock levels now use expandable rows from the shared toolkit

The table under Warehouse → Stock levels now uses the same table component as the rest of the interface - the shared toolkit gains expandable detail rows for the first time. The arrow at the start of a row expands or collapses a product's location breakdown, is reachable by keyboard, and announces its state for screen readers. Loading state and pagination now follow the same look as other lists built on the toolkit.

Unique page titles

Several help pages carried exactly the same name as a page of the same name in another area, which made them impossible to tell apart in search results and listings. Affected in this area: Activity Log (ERP), Reports (ERP) and Locations (ERP). The page addresses do not change, so saved links and bookmarks keep working.

Warehouse area moved to the shared interface controls (technical)

In the warehouse area - stock levels, bins, goods receipt, pack station, returns, warehouse tasks, cycle counting, analytics and the location details - buttons as well as text, choice and multi-line fields now come from the shared interface toolkit instead of each page carrying its own code. Look and handling stay the same; what becomes consistent is keyboard focus, contrast in dark appearance and the behaviour of disabled fields. The tables in this area have not been moved yet and will follow later.

Goods receipts now post stock in a traceable way

Accepting a goods receipt now creates a stock movement with location and reference document, instead of a silent posting that never actually arrived. This concerns background processing; nothing changes in how you use the interface.

Liquidity alerts now actually create a notification

When a liquidity rule under Finance → Liquidity planning triggers, the alert now appears in your notification area - with rule name, metric, current value and threshold, classified as urgent for critical rules. Until now the notification was discarded on write without any error message: the alert fired and was logged, but nobody saw it. Repeated triggers of the same rule within five minutes refresh the existing notification instead of stacking up.

Stock bookkeeping for transfers and returns reworked (technical)

The sales stock of a product is now updated by the product area itself when a transfer is received and when a return is restocked, triggered by a command from the warehouse area. Quantities and timing are unchanged; the rework prepares the separation of the business areas into individual services. If the same command is delivered twice, it takes effect only once.

The lexoffice page no longer shows fabricated results

The connection check under "lexoffice" used to report a green "Connected" badge with a fabricated organization and tax type for any API key of at least 10 characters - regardless of whether a real lexoffice account existed behind it. A webhook URL was confirmed as "successfully registered" without lexoffice ever being notified. That was a fabricated display, not a real check - carrying extra risk for an accounting integration, in case someone relied on a supposedly verified connection. The page now shows only an honest notice that the lexoffice connection has not been set up yet; there is currently no real connection check and no real webhook registration.

List rows and calendar cells are now usable from the keyboard

In the routing rules overview, in stocktaking, in the payment calendar and in the product picker for purchase orders, clickable rows and calendar cells can now be reached without a mouse - tab to them and trigger with Enter or the spacebar.

System event for picking tasks now names the right task

When a picking task is created automatically after a payment is received, the internal system event now reports the identifier of the created task instead of the order. Previously the two reporting paths (immediate notification and event outbox) carried different identifiers; reports or future automations looking up the task through it would have come up empty. Nothing changes in how you use the interface.

ERP lists now work on a phone

The accounting and warehouse pages with special layouts now work on a smartphone (390px) and tablet (768px) without the whole page shifting sideways. Wide tables - the pick list of a running picking wave, the invoice list with its expandable line items, a credit note's line items, the validation history of a VAT ID, the per-location stock in the product drawer, and the AI categorization and price recommendation lists - scroll in their own container instead of being cut off on the right. The seven-day payment calendar keeps its minimum width and scrolls within its own area on narrow screens; the three monthly key figures above it stack vertically on a phone.

Invoice downloads and SEPA files with meaningful names

Invoice PDF and XRechnung downloads now use the file name provided by the system instead of a technical identifier. The SEPA direct-debit file is now named “sepa-lastschriften-<date>.xml” instead of the internal batch ID.

Invoice creation: consistent labels

The company field of the invoice recipient now carries the standard postal label in German, and the capitalisation of invoice line items in the English interface has been unified to "Line items". Labels only - nothing changes in behaviour.

Journal entries: consistent wording for reversals

When reversing a journal entry, the reason field in the German interface is now labelled Stornierungsgrund, matching the wording already used in purchasing. The accounting terms for the reversal entry and the reversal invoice remain unchanged; they name the operation, not the reason.

Saving multiple tags on projects, tasks, stock transfers and B2B accounts works again

Creating or editing a project or project task, a stock transfer or a B2B customer account failed with a server error as soon as you assigned more than one tag. A single tag or none at all could still be saved. The cause was the same faulty hand-over of the tag list to the database as with the bulk actions. Tag lists are now saved correctly - including special characters such as commas or quotation marks.

Bulk editing of products, orders and customers works again

Selecting several entries in the lists and starting a bulk action failed with a server error - this affected every action: change status, set or adjust price, assign category, set tags, assign customer group, archive and delete. Individual entries could still be edited; only the bulk action always came up empty. The cause was a faulty hand-over of the selection to the database, so the action never ran at all. All bulk actions now go through again.

Creating a wave from selected picking tasks works again

Under Warehouse → Wave picking, creating a wave manually from several selected tasks failed with a server error. The selection is now handed over to the database correctly and the wave is created.

CSV export of the demand forecast with a product filter works again

Under Analytics → Demand forecasting, the export failed as soon as you narrowed it down to specific products. The export now completes with a product filter as well.

Lowest price of the last 30 days is determined again in product lists

The batch price-history query that derives the lowest price of the last 30 days for several products at once failed. It returns values again.

Price recommendations for a product selection work again

Under Pricing → Price recommendations, generating recommendations failed as soon as you narrowed it down to specific products. Without that restriction the run completed. The restriction now works again.

Supplier names in the purchase-order list are shown again

Under Procurement → Purchase orders, the supplier column stayed empty in the list because the names were no longer loaded in the background. No error was shown - the list simply looked incomplete. The names are back.

Cashflow overview no longer crashes while loading

The overview on the cashflow page could break into a blank page while the figures were still loading. The cause was a calculation running too early. The page now builds completely in every case.

Import now declines oversized files up front

Product imports now enforce sensible limits - at most 10 MB per file, 50,000 rows, 200 columns, and 64 KB per cell. Files that exceed a limit are rejected with a clear message and nothing is imported, so a single very large upload can no longer slow down the shop. Simply split the file into smaller parts and import them one after another.

Risk, supplier rating & Mirakl metrics explained

The Vendor KYC, supplier management and sales channel help pages now explain how the risk score, supplier overall rating and Mirakl performance metrics are derived and how you can influence them.

Technical refresh of the ERP interfaces

Inventory & stock (warehouse, wave picking, stocktaking, serial/batch tracking, location groups, routing, channels, shipping carriers), accounting & bookkeeping (chart of accounts, journal, balance sheet, P&L, DATEV/lexoffice export, e-invoicing, banking, receipt capture, anomaly detection), procurement (suppliers, purchase orders, goods receipts, quotes) and the pricing & analytics tools (price recommendations, tiered pricing, cashflow, demand forecasting, liquidity, scenario planning, Mirakl) were migrated internally to the unified SCS UI kit. Behaviour is unchanged - in some places forms, tables and buttons now look a little more consistent. Special visualisations such as charts (cashflow, forecasts), timelines (purchase orders, quotes) and the payment calendar deliberately keep their custom layout.