Warum laufen meine Sage-100-Auswertungen nach jedem Update nicht mehr?

Von /

Sage 100 hat einen Vorteil, den viele Warenwirtschaften nicht haben: Die Daten liegen in Microsoft SQL Server. Das verleitet dazu, Auswertungen direkt in die Sage-Datenbank zu bauen. Eine Sicht hier, eine gespeicherte Prozedur dort, ein Excel mit direkter Verbindung. Das funktioniert, bis das nächste Update kommt.

Dieser Beitrag zeigt, wie du Sage 100 sauber an SQL Server und Access anbindest. Mit einer eigenen Auswerte-Datenbank neben Sage, nicht in Sage. Und warum das der Unterschied zwischen einer Auswertung ist, die drei Jahre hält, und einer, die nach drei Monaten bricht.

Was Sage 100 ist und für wen

Sage 100 ist die ERP-Software der Sage GmbH aus Frankfurt am Main für kleine und mittlere Unternehmen. Sie besteht aus Hauptpaketen für Rechnungswesen, Warenwirtschaft, Produktion und xRM, jeweils in den Ausprägungen Basic, Professional und Enterprise. Hunderte Sage-Partner in Deutschland, Österreich und der Schweiz bauen Branchenlösungen darauf auf.

Sage 100 wird aktiv gepflegt. Die aktuellen Systemvoraussetzungen tragen die Versionsnummer 9.0.11 vom Mai 2026. Neben der klassischen Kaufversion gibt es Sage 100cloud als Mietmodell sowie die Smart Edition, eine Oberfläche ohne Microsoft Access.

Ein wichtiger Hinweis, bevor du weiter suchst: Es gibt mehrere Produkte namens „Sage 100“. Die US-amerikanische Sage 100 (früher MAS 90) und die französische Sage 100 sind technisch andere Systeme. Wer nach „Sage 100 API“ oder „Sage 100 ODBC“ googelt, landet oft bei den US-Varianten. Dieser Beitrag behandelt ausschließlich die deutsche Sage 100.

Wo Sage 100 seine Daten speichert

Sage 100 ist eine mehrschichtige Anwendung unter Windows. Die Daten liegen in Microsoft SQL Server, davor arbeitet ein Applikationsserver. Die klassische Oberfläche basiert laut Sage auf der 32-Bit-Version von Microsoft Access 2019 als Laufzeitumgebung.

Für dich als Access-Anwender ist das eine gute Nachricht: Die Technik ist vertraut, und es gibt keinen exotischen Datenbanktreiber. SQL Server spricht mit SQL Server.

Eine Besonderheit betrifft die Lizenz. Sage liefert den SQL Server oft mit, als sogenannte Runtime- oder ISV-Lizenz. Solche Lizenzen sind an das Produkt gebunden, mit dem sie gekauft wurden. Eine eigene Auswerte-Datenbank gehört deshalb nicht ohne Weiteres auf dieselbe Instanz. Hinzu kommt: Sage hat im April 2026 angekündigt, dass die Vereinbarung mit Microsoft über Runtime-Lizenzen am 31. Juli 2026 endet. Diese Ankündigung habe ich nur über US-Partner veröffentlicht gefunden. Ob und wie sie die deutsche Sage 100 betrifft, klärst du mit deinem Sage-Partner.

Eine Auswerte-Datenbank ist eine eigene SQL-Server-Datenbank, die Daten aus Sage und anderen Systemen übernimmt und für Berichte bereitstellt, ohne das Quellsystem zu verändern. Sie ist das Herzstück dieses Beitrags.

Warum Auswertungen in der Sage-Datenbank brechen

Typischer Fehler in KMU: Jemand mit SQL-Kenntnissen legt Sichten und Prozeduren direkt in der Sage-Datenbank an. Das ist bequem, denn die Daten liegen ja da.

Das Problem: Die Sage-Datenbank gehört Sage. Updates können Tabellen und Spalten verändern, Sichten neu anlegen oder Objekte entfernen. Eine fremde Sicht im Sage-Schema ist dann entweder kaputt oder im Weg. Im Supportfall muss außerdem erst jemand klären, welche Objekte von Sage stammen und welche nicht.

Die Faustregel lautet: In der Sage-Datenbank wird gelesen, nicht gebaut. Alles Eigene gehört in eine eigene Datenbank.

Die Zugriffswege im Vergleich

WegAufwandRisikoLizenz und VertragWann sinnvoll
Direkter Lesezugriff auf SQL Server (Linked Server, ODBC)gering bis mittelgering bei reinem Lesen; Schemaänderungen bei UpdatesFreigabe in Sage nötig, ggf. Zusatzoption „Lesender Zugriff“ (siehe unten)Standardfall für Auswertungen und DWH
Datei-Export (Berichte als CSV/Excel, DATEV-Export)gering pro Export, hoch bei Wiederholungmanuelle Schritte, Versionschaosim Standard enthalteneinmalige Migration, Steuerberater-Abgleich
API und Connectoren (Sage-API-Gateway, Partner-Schnittstellen)mittelgering, weil vom Hersteller gepflegtThird-Party-Client-Lizenz bzw. Freischaltung je nach Tarifschreibende Prozesse, Cloud-Anwendungen
RPA (Bildschirmautomatisierung)gering für den Start, hoch im Betriebbricht bei OberflächenänderungenLizenz des RPA-Werkzeugsbei Sage 100 kaum nötig

Zum direkten Lesezugriff zwei Punkte, die ich bei der Recherche gefunden habe. Erstens führt die Sage-100-Modulbeschreibung eine Option „Lesender Zugriff“, die in Sage 100 Connected im Standard enthalten und für Sage 100 Desktop optional ist. Was die Option im Detail umfasst, sagt dir dein Sage-Partner. Zweitens verlangen Drittanbieter für ihre Dienstbenutzer in Sage die Berechtigung „Lesen aus anderen Applikationen erlaubt“. Sage regelt den Fremdzugriff also bewusst. Das ist kein Hindernis, sondern ein Hinweis, das sauber anzumelden.

Zur API: Anbieter von Integrationen nennen als Zugang das Sage-API-Gateway (SData M2M) und weisen darauf hin, dass ein Konto je nach Tarif erst freigeschaltet werden muss. Für reine Auswertungen ist der Weg über die Datenbank einfacher. Für alles, was zurück nach Sage schreibt, ist die API oder ein zertifizierter Connector der richtige Weg.

Für alle Wege gilt: Eigener Login, nur Leserechte, Freigabe durch den Sage-Partner. Wo möglich, laufen große Abfragen gegen eine Kopie oder außerhalb der Arbeitszeit.

Der Weg ins Data Warehouse

Ab hier wird es technisch. Wer nur wissen will, was das fürs Geschäft bedeutet, springt zum Abschnitt „Was du davon hast“.

Die Architektur besteht aus drei Teilen: Sage 100 auf seiner Instanz, eine eigene Auswerte-Datenbank mit Linked Server zu Sage, und darauf Access, Excel, Power BI oder eine KI.

Schritt 1: Auswerte-Datenbank und Linked Server

Das Skript läuft auf dem SQL Server, auf dem die Auswerte-Datenbank liegt. Es verbindet sich mit einem Login, der in der Sage-Datenbank nur lesen darf.

-- Eigene Auswerte-Datenbank, getrennt von Sage 100
CREATE DATABASE Auswertung;
GO
USE Auswertung;
GO
CREATE SCHEMA stg;   -- Rohdaten aus Sage, 1:1
GO
CREATE SCHEMA dwh;   -- bereinigtes Modell für Berichte
GO

-- Linked Server auf die Sage-Instanz
-- Platzhalter: <SAGE_SERVER\INSTANZ>, <LESELOGIN>, <PASSWORT>
EXEC sp_addlinkedserver
     @server     = N'SAGE100',
     @srvproduct = N'',
     @provider   = N'MSOLEDBSQL',
     @datasrc    = N'<SAGE_SERVER\INSTANZ>';

EXEC sp_addlinkedsrvlogin
     @rmtsrvname  = N'SAGE100',
     @useself     = N'false',
     @locallogin  = NULL,
     @rmtuser     = N'<LESELOGIN>',
     @rmtpassword = N'<PASSWORT>';

Liegen Sage und Auswerte-Datenbank aus Lizenzgründen auf derselben Maschine, aber in getrennten Instanzen, funktioniert das genauso. Der Linked Server zeigt dann auf die Sage-Instanz.

Schritt 2: Staging laden

Die Rohdaten kommen unverändert in Staging-Tabellen. Die Tabellen- und Spaltennamen in Sage 100 hängen von Version und Modulen ab. Ich verwende hier bewusst Platzhalter.

-- Verkaufsbelege der letzten 13 Monate neu laden
-- Platzhalter: <SAGE_DB>, <TABELLE_VK_BELEGE>, <TABELLE_VK_POSITIONEN>, Spaltennamen
TRUNCATE TABLE stg.sage_vk_position;

INSERT INTO stg.sage_vk_position
       (Mandant, BelegID, Belegdatum, Kundennummer, Artikelnummer,
        Artikelgruppe, Menge, Nettobetrag)
SELECT b.<Mandant>, b.<BelegID>, b.<Belegdatum>, b.<Kundennummer>,
       p.<Artikelnummer>, p.<Artikelgruppe>, p.<Menge>, p.<Nettobetrag>
FROM SAGE100.<SAGE_DB>.dbo.<TABELLE_VK_BELEGE>     AS b
JOIN SAGE100.<SAGE_DB>.dbo.<TABELLE_VK_POSITIONEN> AS p
     ON p.<BelegID> = b.<BelegID> AND p.<Mandant> = b.<Mandant>
WHERE b.<Belegdatum> >= DATEADD(MONTH, -13, CAST(GETDATE() AS date));

Der entscheidende Punkt ist die Spalte Mandant. Sage 100 ist mandantenfähig, und fast jede Tabelle führt sie mit. Wer sie im Join vergisst, verdoppelt still seine Umsätze.

Schritt 3: Delta-Abgleich ins DWH

Abgeschlossene Monate werden einmal übernommen, offene Monate bei jedem Lauf ersetzt. Das ist einfacher und robuster als ein Abgleich auf Einzelsatz-Ebene, wenn die Quelle keinen verlässlichen Änderungszeitstempel liefert.

-- Offene Monate im DWH ersetzen
DECLARE @ab date = DATEADD(MONTH, -13, CAST(GETDATE() AS date));

BEGIN TRANSACTION;
    DELETE FROM dwh.fakt_umsatz
    WHERE Quelle = 'Sage100' AND Belegdatum >= @ab;

    INSERT INTO dwh.fakt_umsatz
           (Quelle, Mandant, Belegdatum, Kundennummer, Artikelnummer,
            Artikelgruppe, Menge, Nettobetrag)
    SELECT 'Sage100', Mandant, Belegdatum, Kundennummer, Artikelnummer,
           Artikelgruppe, Menge, Nettobetrag
    FROM stg.sage_vk_position;
COMMIT TRANSACTION;

Die Spalte Quelle hält die Tür offen für weitere Systeme: Webshop, zweite Gesellschaft, Altdaten. Alle landen in derselben Faktentabelle, bleiben aber unterscheidbar.

Schritt 4: Schemaänderungen nach Updates erkennen

Nach jedem Sage-Update lohnt ein Abgleich: Gibt es die Spalten, die das DWH liest, noch? Dafür speichert man einmal die benötigten Spalten und prüft sie nach dem Update.

-- Einmalig: Liste der Sage-Spalten, die das DWH benötigt
-- CREATE TABLE dwh.sage_spalten_soll (Tabelle sysname, Spalte sysname);

-- Nach jedem Update: fehlende Spalten anzeigen
SELECT s.Tabelle, s.Spalte
FROM dwh.sage_spalten_soll AS s
LEFT JOIN SAGE100.<SAGE_DB>.INFORMATION_SCHEMA.COLUMNS AS c
       ON c.TABLE_NAME = s.Tabelle AND c.COLUMN_NAME = s.Spalte
WHERE c.COLUMN_NAME IS NULL;

Liefert die Abfrage Zeilen, läuft der nächtliche Ladeprozess nicht los, sondern meldet sich. Das ist der Unterschied zu Sichten im Sage-Schema: Der Fehler fällt vor dem Bericht auf, nicht im Bericht.

Was du davon hast

Diese Auswertungen werden bei Sage-100-Anwendern am häufigsten gebraucht:

  • Umsatz je Kunde und Artikelgruppe über mehrere Jahre, als Excel-Pivot direkt aus der Auswerte-Datenbank, ohne Export.
  • Offene Posten je Kunde im Zeitverlauf: Wer zahlt zunehmend später? Das sieht der Vertrieb, bevor die Mahnung rausgeht.
  • Deckungsbeitrag je Artikelgruppe, kombiniert mit Einkaufspreisen und Rabatten.
  • Mehrere Mandanten oder Systeme in einem Bericht, etwa Sage 100 plus Webshop oder plus eine zugekaufte Firma mit anderer Software.

Access passt hier besonders gut: Die Auswerte-Datenbank wird verknüpft, und Fachabteilungen bauen ihre Abfragen auf bereinigten Tabellen statt auf Sage-Rohtabellen.

Neu ist der KI-Zugriff. Über einen MCP-Server, einen standardisierten Zugang für KI-Assistenten wie Claude, kann eine KI Fragen in normaler Sprache gegen eine Datenbank stellen. Die richtige Datenbank dafür ist die Auswerte-Datenbank, nicht Sage. Dort liegen verständliche Spaltennamen, die Mandanten sind sauber getrennt, und keine KI-Abfrage bremst die Warenwirtschaft aus.

Eine KI ist nur so gut wie die Tabelle, die sie liest. Struktur zuerst, dann KI.

Wo dieser Ansatz an Grenzen stößt

Die Auswerte-Datenbank liest. Sie ersetzt keine Sage-Funktion, und wer Daten zurück nach Sage schreiben will, nutzt die Schnittstellen und Connectoren von Sage, nicht die Datenbank.

Bei Sage 100cloud im Hosting hängt der Datenbankzugriff vom Hosting-Paket ab. Das klärst du vorher.

Und die Tabellenlandkarte kostet einmal Zeit. Wer Sage 100 nicht kennt, sucht anfangs länger nach der richtigen Belegtabelle als nach der richtigen Abfrage.

Was das für dich als Geschäftsführer bedeutet

Sage 100 bleibt, was es ist: deine Warenwirtschaft und Buchhaltung. Daneben entsteht eine eigene Datenbank, in der Sage-Daten mit allem anderen zusammenkommen. Updates von Sage brechen deine Berichte nicht mehr, weil sie nicht mehr in Sage stecken.

Der Aufwand beginnt mit deinen drei wichtigsten Fragen, nicht mit einem Systemprojekt. Und wenn irgendwann doch ein Wechsel ansteht, liegt die Historie schon sauber in SQL Server.

Wenn du Sage 100 im Haus hast und deine Auswertungen nach Updates regelmäßig kaputtgehen, schau ich mir das gern an. Für einen ersten Blick reichen ein lesender Zugang und eine Liste deiner wichtigsten Berichte. Erreichbar bin ich über sesoft.de/kontakt oder über ein kostenloses Erstgespräch.

Häufige Fragen

Darf ich direkt auf die SQL-Datenbank von Sage 100 zugreifen? Lesend in der Regel ja, wenn es sauber angemeldet ist. Sage regelt Fremdzugriffe über Berechtigungen, und die Modulbeschreibung führt eine Option „Lesender Zugriff“. Kläre den Umfang mit deinem Sage-Partner.

Warum nicht einfach Sichten in der Sage-Datenbank anlegen? Weil Updates das Sage-Schema verändern können. Eigene Objekte gehören in eine eigene Datenbank. Dann bleiben sie bei Updates unberührt und sind im Supportfall klar von Sage-Objekten getrennt.

Kann die Auswerte-Datenbank auf dem SQL Server von Sage liegen? Technisch ja. Lizenzrechtlich ist das zu prüfen: Wird SQL Server als Runtime-Lizenz mit Sage geliefert, ist er an Sage gebunden. Eine eigene Instanz mit eigener Lizenz ist der saubere Weg.

Gibt es eine API für Sage 100? Ja, Integrationsanbieter nutzen das Sage-API-Gateway, je nach Tarif mit Freischaltung. Für Auswertungen ist der Datenbankweg meist einfacher, für schreibende Prozesse die API.

Ich finde im Netz nur englische Anleitungen zu Sage 100. Passen die? Meist nicht. Die US-amerikanische und die französische Sage 100 sind andere Produkte mit anderer Technik. Achte darauf, dass sich eine Anleitung auf die deutsche Sage 100 der Sage GmbH bezieht.

Quellen

Über den Autor

Sönke Schäfer ist IT-Berater und Datenarchitekt aus Sierksdorf in Ostholstein und arbeitet seit über 25 Jahren mit Microsoft Access, VBA und SQL Server. Er baut für norddeutsche Mittelständler Auswerte-Datenbanken neben bestehenden Warenwirtschaften wie Sage 100, microtech büro+ oder WinWorker, damit Berichte, Access-Anwendungen und KI-Assistenten auf saubere Daten zugreifen, ohne dass das ERP angefasst oder gewechselt werden muss.</p>

Ähnliche Beiträge

Nach oben scrollen