Everything laeuft does.

laeuft reads new Amazon orders through the Selling Partner API on a fixed schedule, with buyer, delivery address, items and payment state. Each order lands in the same order list as every other channel and keeps its Amazon order number for later steps like shipping confirmation and invoice upload.

eBay orders are read through eBay's own interface on a fixed schedule, including buyer, address and payment. They appear in the shared order list and keep the eBay order reference for everything that follows.

laeuft reads Kaufland.de orders through the Kaufland seller API on a fixed schedule. They show up next to Amazon, eBay and the rest, with the same statuses and filters.

You connect your shop once by approving the laeuft app in Shopify; laeuft stores the access encrypted for your company. From then on orders arrive automatically and you can jump from any order straight into Shopify.

MediaMarkt DE, MediaMarkt AT, Voelkner and Conrad all run on Mirakl, so laeuft connects each of them through the same Mirakl interface with its own shop credentials. Orders, offers and the documents the operator asks for go through that one connection per shop.

All channels and your own B2B orders share one order list. You filter by channel, status or payment, open an order in a side panel and see its whole path: stock, pick, pack, label, invoice, payment.

When a label is booked, laeuft builds the shipping confirmation in the format each channel expects, with carrier and tracking number. Each channel is switched on separately (off, shadow or live), and the shipping monitor shows orders whose confirmation has not arrived yet.

Every article has a number, GTIN, brand, texts, attributes and a lifecycle status: draft, active, phasing out, blocked or discontinued. Status decides whether an article may be sold and reordered; articles are never deleted, so orders and documents keep pointing at them.

A set has its own number, price and offers but no stock of its own: its availability is calculated from its components. When it sells, the components are recorded on the order, picked and scanned one by one, and a later change to the set never alters existing orders.

Each article knows how many pieces one unit contains. Singles of the same goods can fill demand for a pack, but only upwards and only in whole packs; a pack is never split to serve singles.

Articles that are physically the same goods under different brands or numbers form an exchange group. Any member can fulfil an order for any other, so stock is counted once and sold everywhere; groups are only linked after you confirm them.

laeuft takes over your existing catalogue once, in stages, and from then on every change is a revision with who, when and before/after. If the old system still changes an article afterwards, laeuft shows the field as a difference that you accept or discard; nothing is overwritten automatically.

Titles are proposed for each connected marketplace within its length rules, and a pattern found for one variant is reused for its siblings. Nothing is published until you review it. Available today via Sievate Attributes and being built into laeuft next.

Each marketplace has its own attribute schema. Values are filled per marketplace, matched to the allowed entries where only listed values are accepted, and related fields like length and unit are filled together. Your fixed values and guidance apply first. Available today via Sievate Attributes.

Titles are scored on length fit, similarity to titles that sell, keywords and information density. Weak scores point you to the listings worth fixing first. Available today via Sievate Attributes.

After publishing, each listing is checked directly at the marketplace: status, offer, attributes and processing errors. A deviation is diagnosed with the marketplace's own message, repaired and verified again; what can't be fixed automatically lands with you. Available today via Sievate Attributes.

laeuft calculates one available quantity per article before channel rules apply: free stock across sites, interchangeable articles and fillable packs, minus demand that nothing else covers. Every channel offer publishes from that number, so you never sell the same piece twice.

Each channel offer links an article to the channel's SKU and offer, with optional exceptions like handling time, fixed or minimum price and maximum quantity. laeuft reads what the channel currently shows and flags every offer where a feed would change stock, price or handling time.

Prices come from rule sets: purchase price, margin rule, channel fee, shipping share and VAT add up to the channel price, and every price shows that calculation. Rule sets are versioned and released with an effective date; each channel picks its price target, with optional rounding and min/max per offer.

Orders that come by phone or e-mail are created in laeuft for a direct customer, with prices, discounts, payment terms and delivery address. Once confirmed they get an order number and go through the same floor, invoice and payment steps as marketplace orders.

A quote has versions: only the newest draft is editable, and every version you send is frozen. When the customer accepts the current version, laeuft creates a confirmed order with exactly its prices, discounts and terms, without recalculating.

Orders, quotes, customers, invoices and credit notes each get their own number range, with the year in the number where it makes sense (for example AU26-00001). Numbers are assigned in the same step as the document itself, gapless and never twice.

Direct customers carry addresses, contacts, VAT ID, payment terms and, for public buyers, a Leitweg-ID that laeuft checks against its check digit. New orders and quotes copy these values as a snapshot, so a later change to the customer never rewrites a confirmed order.

Documents carry a QR code that opens an order page on your own domain, showing status, tracking and invoice. The link is a signed token per order: laeuft stores only its hash, can expire or revoke it, and limits requests per visitor.

Each shipping card carries its own review code. For an Amazon order it leads straight to the review of that order, otherwise to your review page, for example on Google. laeuft counts cards and scans per channel and device, without bots and link previews, and every scan links back to its order.

Every site and bin feeds one stock per article, so availability, picking and transfers all work from the same numbers. You see per site what is free, reserved, in transit or already promised to open orders.

Stock is kept per bin (for example B-07-3), so the floor always tells you exactly where to go. Corrections and manual reservations are bookings with a reason, not silent overwrites.

At the times you set, laeuft bundles what open customer orders still need into one supplier order and counts earlier orders as already on their way, so nothing is ordered twice. Extra quantities can be added by hand. The supplier collects the order on its own page and reports per line what arrives when or cannot be delivered; goods-in sees the delivery as an expected list.

At goods-in you scan what arrives; laeuft resolves the barcode to the article and tells you where it goes, whether to an open order or a bin. Expected deliveries are listed together, so the team works through one list instead of paperwork.

If a scan finds no article, the floor asks which article it belongs to. Once assigned, that barcode works everywhere in laeuft, and the open tasks waiting for it are listed so the team can work them off.

Where an article is scanned in, at goods-in, distribution or returns, the floor prints as many labels as you need: barcode, article number and name on a 62 × 29 mm label. The barcode is the article’s EAN-13 where it has one, otherwise a Code 128 of the article number.

When one site needs stock from the other, laeuft creates the transfer demand and a mobile pick list for the sending site. Picked goods count as in transit until they are scanned in at the receiving site.

Every booking on the floor has an undo, in any state, step by step like a stack. A mistake is corrected with a counter-booking, so the history stays complete.

The floor runs in the browser on phones, handheld scanners and packing stations, so there is nothing to install. Each device signs in with its role and only sees the work for its site.

There is also a native iPhone app that uses the camera as a scanner. It runs the same capabilities as the browser floor, so permissions and bookings are identical.

Each floor screen shows exactly one next step: the article, the quantity in large digits, the bin and one button. Hints never take over the main button, so the flow stays the same every time.

laeuft releases orders to the floor once stock, payment and holds allow it, and sorts the pick path by bin. Each pick is confirmed by scanning the article or bin; a missing item becomes a reported problem instead of a guess.

Orders with several items are collected in a numbered shipping box until all their items are there. Only then does the order move on to packing, so incomplete parcels never leave.

At the packing table every item is scanned against the order. A wrong or extra scan stops the parcel before a label is booked, and the weight is captured for the carrier.

laeuft books DHL parcels, small parcels and international shipments directly through the DHL Parcel DE API with your own customer number. The label comes back in seconds and prints at the packing table; no DHL portal is involved.

GLS parcels are booked and cancelled through the GLS web API with your own access. The label prints like every other label, at the table where the parcel is packed.

Letters and Warenpost are franked through Deutsche Post Internetmarke from your own postage account. Rules decide when a letter is allowed; for example, business customers always get at least a small parcel.

A small print agent on the PC at the packing table receives print jobs from laeuft and sends them to the Zebra label printer. Printing happens only when someone taps print, and the button shows whether the job arrived.

From the shipping history you reprint any label or cancel it at the carrier. A cancelled label is recorded with time and person, so carrier invoices can be checked against it later.

The Internetmarke postage balance is shown in the floor header. Before it runs low, laeuft tops it up automatically by a set amount, so letters never stop at the packing table.

Each shipping method carries its size and weight limits and a dimension sketch, shown when the packer chooses it. laeuft suggests the method from the order and its rules, and the packer confirms or changes it on the grid.

Scan any parcel label or search an order to see what went into the parcel, who packed it, when, with which method and which tracking number. From there you reprint, cancel or correct the weight.

The monitor lists orders that are overdue against the channel's shipping deadline and shipments the channel has not been told about yet. For each one you can promise a new date, so the late ones are handled before they turn into channel penalties.

Daily figures per site: parcels, shipping methods and carriers, and how long it took from order to label and from label to packed. The numbers come straight from the shipping bookings.

Before a label is booked, an AI check looks at the address. Formal fixes such as a mistyped postcode or street spelling are applied automatically and logged; anything unclear goes to the inbox for a person.

At the returns desk you start with a photo of the parcel or label; laeuft reads it, suggests the matching order and lets you confirm. Each item is then checked, stored back on a bin or disposed of, and every step can be undone.

laeuft creates return labels with DHL or GLS for a customer and attaches them to the return case. A rule per company decides who pays, and the label's tracking number is used to match the parcel at intake.

After intake, laeuft issues the credit note and prepares one refund per correction, built for the channel's own refund call. Standard returns can be released automatically; everything else waits for a person, and nothing is paid out before it is approved.

laeuft issues the invoice from the shipped order and the credit note from the return, each with its own number range. Documents are never edited after issue; a correction is a cancellation or credit note that refers to the original.

If you release a partial delivery, each delivery gets its own invoice with the quantities actually shipped. Shipping costs go on the first partial invoice, and the last one takes exactly the remainder, so the total is right to the cent.

Every invoice is generated from one document model: a PDF/A-3 with embedded ZUGFeRD XML for people and machines, and a pure XRechnung where the buyer needs it. Both carry the same numbers because they come from the same data.

Public buyers are marked by a Leitweg-ID on the customer, checked by its check digit when you enter it. It is copied into each order and quote and written into the XRechnung as buyer reference; per order you can set a different department.

laeuft determines the tax case per order (domestic, OSS distance sale, intra-EU, export) and the rate per line from the article's tax category and the destination country. Shipping and fees follow the goods, split proportionally when an invoice mixes rates.

Per channel you set how documents are delivered: uploaded to the order (Mirakl, Amazon, Kaufland), mailed to the buyer, mailed to a fixed operator address, or deliberately not at all with a reason. A required upload that fails is never silently replaced by an e-mail.

laeuft reads your Qonto accounts through the Qonto API every few minutes, read-only, and fetches the last 90 days on first connect. A daily re-scan picks up transactions Qonto changed later; laeuft never sends a transfer.

Postbank statements come in through FinTS with decoupled TAN approval, several times a day. Like every bank source, the connection only reads; transfers stay in your banking.

laeuft reads PayPal transactions through the PayPal API, including fees, and looks up the order behind each payment. Payments and fees are matched to their invoices and booked separately.

laeuft fetches the transaction reports of Amazon, eBay, Kaufland, Shopify and the Mirakl marketplaces through their APIs. Each payout is split into orders, refunds, fees and other costs, so the bank line of the payout is explained to the cent.

For any bank without a direct connection you upload statements as CAMT, MT940 or CSV. They go into the same bank feed as connected accounts, so matching and open items work the same way.

Fixed rules decide: references in the payment text (invoice, order or channel order number) and the amount have to fit an open item. AI only ranks candidates; anything not clear goes to a person, and a payment advice can split one transfer across several invoices.

An open item is the invoice minus corrections minus confirmed payments. You see what is still unpaid per customer and channel, and an incoming prepayment releases the order for shipping on its own.

Three levels (payment reminder, first and second reminder) with days, fees and new payment terms you configure, separately for business customers. laeuft drafts each run from the open items; you check and release it, and sending sits behind its own switch.

From invoices, credit notes, payouts and bank lines, laeuft prepares the bookings: revenue, fees and payouts on accounts you define per rule, based on SKR03. Every booking keeps a link to the document it came from.

Bookings are handed over in DATEV format per month, and each one links to its document image so your accountant sees the invoice behind it. Uploads to production only start once you switch them on for your company.

Before a month is handed over, laeuft shows what is still open: bank lines without a match, payouts not yet split, exceptions to check. You close the month when the list is empty.

You upload the carrier's invoice file; laeuft maps its columns once (AI suggests, you confirm) and matches every line to a parcel by tracking number. Weight differences, labels billed after cancellation, unknown parcels and duplicates are listed for you.

Once carrier invoices are matched, every parcel carries its real cost. laeuft adds it up per order and per channel, so you see what shipping really costs where you sell.

Every action in laeuft is defined once as a typed capability with input, output, permission and risk level. The app, the HTTP API, the CLI and the MCP server are generated from that registry and call the same business logic.

Every capability is available under /api/v1, described as OpenAPI 3.1 so you can generate clients. Requests use the same permissions, business errors and idempotency as the app.

The laeuft command line calls any capability by name, for scripts, cron jobs or quick checks from the terminal. It authenticates with an agent token and follows the same approval rules.

laeuft runs an MCP server at app.eslaeuft.com/mcp. Connect any MCP client with an agent token, and its tools are exactly the capabilities that agent is allowed to use.

Each agent is its own identity with a name, a subset of its creator's permissions and an optional expiry. The token is shown once and only its hash is stored; it stops working when revoked, expired, or when its creator leaves the organisation.

Read: any query, agents run it. Write: changes inside laeuft that can be corrected, agents run it. Consequential: reaches a carrier, channel, bank or customer and needs approval. Critical: settings, access and agents. People only, never approvable.

When an agent calls a consequential capability, laeuft records the exact request and puts it in the inbox instead of running it. A person approves or declines; only then does it run, unless that agent was explicitly allowed to act on its own for exactly this capability.

Every change records who did it (person or agent), what changed and when. Personal data is named by field, not copied into the log.

Some routine already runs on its own: formal address fixes before labels, matching return photos to orders, and splitting payouts and matching payments. Each of them logs what it did and hands anything unclear to the inbox.

The inbox collects only what needs a person today: a failed booking, an unclear address, an approval, a difference to check. Each item comes with its typed action; items that only inform close themselves once the cause is gone.

⌘K opens a palette that searches orders, articles, customers and actions at once. Areas have their own keys (G then a letter), and every action shows its shortcut, so the office works without the mouse.

laeuft is built on a real-time database: when something changes, every open screen updates by itself. A scan at the packing table shows up in the office the same second, without reload.

The office, the floor and the API all run in the cloud and open in any current browser. There is no client to install, no server in your office and no remote desktop.

Permissions are granted per role: the office, the warehouse floor and the returns desk each get only the areas they need. The same permissions apply in the app, the API and to agents.

Channel, carrier, bank and mail credentials are stored per company and encrypted. They are only decrypted at the moment a call needs them, and you manage them under Settings → Access.

Every outward effect (documents, confirmations, refunds, uploads) has a switch per area: off, shadow or live. In shadow, laeuft builds everything and compares it with your current system without sending anything; you go live per area when the numbers match.

laeuft sends mails such as return confirmations through your own Microsoft 365 mailbox, connected once in the settings. Buyers see your address, and the sent mails stay in your mailbox.