Forhandler- og franchisetvister: salgsdata og systemadgang

I et franchise- eller forhandlerforhold arbejder to virksomheder i de samme systemer: kassesystem, webshop, ordreportal, CRM, bookingsystem og ofte en fælles mail- eller intranetløsning. Når samarbejdet går i stykker, er det næsten altid den ene part, der administrerer systemerne. Den anden part har kun en brugerkonto, og den kan blive lukket fra den ene dag til den anden.

For advokaten betyder det, at bevissituationen er skæv fra starten. Den part, der ejer systemerne, kan se alt. Den anden part ser kun det, en almindelig bruger kan se. Denne artikel gennemgår, hvilke data der typisk findes, hvem der har dem, og hvad der skal sikres først. Hvordan kontrakten skal forstås, og hvilke krav der kan rejses, er advokatens vurdering.

Typiske stridspunkter og de data, der belyser dem

Opgørelse af omsætning og afgifter · Kassesystem, regnskabssystem, rapporter fra franchiseportalen
Kundeforhold efter ophør · CRM, kundeklub, nyhedsbrevslister, ordrehistorik
Brug af kendetegn efter ophør · Hjemmeside, profiler på sociale medier, annoncer
Overholdelse af koncept og krav · Indberetninger, kontrolrapporter, korrespondance
Konkurrerende virksomhed · Domæner, nye profiler, overførsel af kunder
Ejerskab til konti · Domæne, annoncekonti, sociale medier, bookingsystem

Den sidste række overses ofte. Domæner, annoncekonti og profiler er tit oprettet af den lokale forhandler, men med kæden som administrator, eller omvendt. Hvem der juridisk ejer kontoen, og hvem der teknisk har adgangen, er ikke nødvendigvis det samme. → Hvem ejer domænet og kontoen?

Hvem har hvilke data?

Udgangspunktet er enkelt at beskrive, men svært at håndtere:

Franchisegiveren eller leverandøren har typisk administratoradgang til de fælles systemer, adgang til rålogs og mulighed for at eksportere data for alle enheder.
Franchisetageren eller forhandleren har sine egne lokale data: egne regnskabsposteringer, bankkonto, mails, egne kopier af rapporter og ofte en lokal kasse eller betalingsterminal.
Systemleverandøren bag kassesystemet eller webshoppen har driftslogs og backup, som ingen af parterne nødvendigvis kan se.
Betalingsindløseren har transaktionsdata, der kan bruges til at kontrollere omsætningstal fra kassesystemet.

Et eksempel: En kæde opgør afgiften ud fra omsætningen i det fælles kassesystem, mens forhandleren mener, at returvarer og rabatter er talt forkert med. Her kan kassesystemets transaktionsdata sammenholdes med indløserens udbetalinger og forhandlerens bogføring. Tre uafhængige kilder giver et langt stærkere billede end én rapport fra systemet. → Bevissikring af regnskabssystemer

Adgang efter ophør: det største risikopunkt

Når samarbejdet ophører eller opsiges, lukker den administrerende part ofte adgangen med det samme. Det kan være kontraktmæssigt i orden, men det betyder, at den anden part mister muligheden for at hente sine egne data. Omvendt kan den part, der stadig har adgang, ændre, slette eller eksportere data, før en tvist er formuleret.

Hvis klienten er den svage part i systemerne

Rådet er at sikre så meget som muligt, mens adgangen stadig findes, og helst før ophøret meddeles:

Eksportér rapporter over omsætning, afgifter og ordrer for hele samarbejdsperioden i det format, systemet tilbyder.
Gem kundelister og korrespondance, som klienten lovligt har adgang til.
Dokumentér skærmbilleder af indstillinger og rettigheder, så det fremgår, hvad klienten kunne og ikke kunne se.
Notér tidspunkter og beregn hashværdier for eksporterne, så det senere kan vises, at de ikke er ændret.

Skærmbilleder alene er sjældent nok, men de kan dokumentere brugerfladen som supplement til eksporterede data.

Hvis klienten administrerer systemerne

Her er opgaven en anden: at sikre, at intet ændres, og at det kan dokumenteres. Det indebærer at bevare logs, udsætte automatisk sletning og registrere, hvem der lukkede hvilke adgange og hvornår. Når klienten selv har kontrol over beviserne, bliver det vurderet kritisk, hvis data forsvinder. → Bevarelsespligt og litigation hold

Hvad logs kan og ikke kan vise

Fælles systemer har ofte en revisionslog, der viser log ind, ændringer og eksport. Den kan dokumentere, at en bestemt bruger eksporterede kundelisten en bestemt dag, eller at en pris blev ændret centralt.

Logs har dog grænser:

En brugerkonto er ikke det samme som en person. Mange butikker deler logins ved kassen.
Logs gemmes i en begrænset periode, som afhænger af systemet og abonnementet.
En rapport i systemet er en beregning. Hvis beregningsreglen er ændret undervejs, kan gamle og nye rapporter vise forskellige tal for samme periode.
Data, der er slettet af administratoren, kan være væk for brugerne, men kan stadig findes i systemleverandørens backup.

Bed derfor om rådata frem for færdige rapporter, når det er muligt, og om dokumentation for, hvordan rapporterne beregnes. → Bevissikring af CRM-systemer

Når modparten har dataene

Ligger beviserne hos modparten eller systemleverandøren, er en editionsbegæring ofte vejen. Den tekniske del handler om at præcisere, hvad der skal udleveres: hvilket system, hvilken periode, hvilke felter og hvilket format. En begæring om “alle salgsdata” er svær at efterkomme og svær at kontrollere. En begæring om transaktionsdata fra kassesystemet for bestemte butikker i en bestemt periode, i et maskinlæsbart format med alle felter, er langt mere præcis. → Editionsbegæring om digitale beviser

Er der tale om et samarbejde, der har udviklet sig til en egentlig ejertvist, gælder mange af de samme overvejelser. → Ejertvist og partnerbrud

Spørgsmål til klienten

Hvilke systemer bruges i samarbejdet, og hvem administrerer dem?
Har klienten stadig adgang, og hvornår forventes den lukket?
Hvem har oprettet domæne, annoncekonti og profiler på sociale medier, og hvem står som administrator?
Hvilke rapporter har klienten løbende modtaget eller gemt?
Bruger flere medarbejdere samme login?
Er der lokale systemer, fx en kasse eller en betalingsterminal, som kun klienten har adgang til?

Spørgsmål til skønsmanden

Stemmer omsætningen i kassesystemet overens med betalingsdata og bogføring for perioden?
Viser systemets logs ændringer i priser, rabatter eller beregningsregler, og hvornår?
Hvornår blev en bestemt brugers adgang lukket, og af hvem?
Er der eksporteret kundedata fra systemet efter en bestemt dato, og fra hvilken konto?

Typiske fejl

Adgangen lukkes, før nogen har sikret data, der skal bruges i sagen.
Kun systemets færdige rapporter fremlægges, ikke de underliggende transaktioner.
Ejerskab til domæner og konti undersøges først, når de bliver brugt af modparten.
Logs slettes automatisk, fordi ingen har stoppet den normale oprydning.