Frequently asked questions about EDMS

An Electronic Document Management System is software that captures, stores, organises, secures and tracks an organisation's documents through their entire life, from creation or scanning to eventual archiving or destruction. A true EDMS does more than store files: it applies metadata so documents can be found, enforces version control so there is one authoritative copy, routes documents through approval workflows, restricts access by role, records an audit trail of every action, and applies retention rules that govern how long each record is kept and what happens to it afterwards.

The terms overlap and are often used interchangeably in tenders. A DMS (document management system) is the general term for storing and retrieving documents. An EDMS adds the electronic capture, workflow and control layer. An EDRMS (electronic document and records management system) explicitly adds records management: retention schedules, record declaration, disposition and archival transfer. ECM (enterprise content management) is the broadest term, covering documents plus web content, media and other unstructured content. EDMS by Sibasi covers all of the EDMS and EDRMS capability set, and extends into the wider content management surface through Microsoft 365.

Any organisation that has to prove what it holds, who saw it, and how long it was kept. In practice the strongest need is in government ministries, county governments, state corporations and regulators; banks, SACCOs, microfinance institutions and insurers; hospitals and health institutions; law firms and professional practices; universities and colleges; NGOs and development programmes with donor audit obligations; and energy, manufacturing and utility operators with engineering document control requirements.

Not out of the box. SharePoint provides the platform: storage, versioning, permissions, search and integration with Microsoft 365. It does not arrive with your file plan, your retention schedules, your approval workflows, your metadata model or your registry processes — and those are what an EDMS actually is. EDMS by Sibasi is the product built on top: the configuration, intellectual property and governance layer that turns a SharePoint tenant into a working document and records management system, delivered as a defined deployment rather than a build-it-yourself project.

Four things. It classifies incoming documents so it knows a contract from an invoice from a minute, and files them accordingly. It extracts the fields that matter — counterparty, dates, amounts, reference numbers — into searchable metadata, so nobody types them in. It applies retention labels based on what the document is, so retention no longer depends on someone remembering. And through Microsoft 365 Copilot it lets people ask questions in plain language across the documents they are permitted to see, with a citation to the source document for every answer.

Yes. That is a large part of the point. Documents can be filed to the correct library directly from the Outlook reading pane, with the email metadata preserved. Approval tasks arrive in Microsoft Teams and can be actioned without opening a separate portal. Files sync through OneDrive for offline work and reconcile when the connection returns. Because the repository is SharePoint, documents open in the desktop and web versions of Word, Excel and PowerPoint with version control intact.

Yes. EDMS by Sibasi deploys on SharePoint Online in your Microsoft 365 tenant, on SharePoint Server inside your own data centre, or as a hybrid where sensitive records stay on premises while collaboration runs in the cloud. Where residency rules require data to stay in a particular country, a dedicated Azure region deployment is also available. Some AI capabilities depend on cloud services; we make the trade-off explicit at design stage rather than after signature.

Yes. The system supports offline access through OneDrive sync, progressive and thumbnail-first document loading so previews arrive before full files, and mobile capture that queues and uploads when a connection is available. This matters for county offices, branch networks and field sites, and it is a specific design consideration rather than an afterthought.

Yes. Integration is delivered through Microsoft Graph and REST APIs, Power Automate connectors and webhooks. Typical integrations link the EDMS to finance and ERP systems so invoices and supporting documents stay attached to the transaction, to HR systems so personnel documents follow the employee record, and to case or core banking systems so the document file and the operational record stay in step. Systems without a modern API are handled with a purpose-built integration layer, scoped separately.

EDMS by Sibasi is priced as a deployment, not a per-user subscription. Basic Deployment starts from USD 5,000 and delivers a governed repository with metadata, search, versioning and access control. Standard Deployment starts from USD 25,000 and adds workflow automation, audit trails, Outlook and Teams integration and mobile access. Premium Deployment starts from USD 65,000 and adds AI classification, records management and retention, digitisation and migration, and integration with your line-of-business systems. Final pricing depends on scope — how many departments, how many processes, how much paper there is to digitise and how many systems to integrate.

No, and that usually works in your favour. Microsoft 365 or SharePoint licences are bought in your own name, from us or any partner you choose. Most organisations that need an EDMS already hold them: Microsoft 365 Business Premium, E3, E5 and the non-profit and academic equivalents all include SharePoint. Because the platform is already licensed, there is no second per-user subscription for the document system — which is the structural cost difference against a standalone EDMS product charged per user per month, indefinitely.

The deployment price covers design, configuration, deployment, setup, training and a warranty period. After that, annual maintenance and managed service is optional and priced separately — it covers platform administration, enhancement hours, support with defined response targets and a quarterly service review. Organisations with internal Microsoft 365 capability often take support only; organisations without it usually take the managed service.

Yes. We submit full technical and financial responses to EDMS procurements across the region, covering architecture, implementation methodology, team experience, references, service levels and a priced bill of quantities. Where a local-content or joint-venture condition applies, we also bid as part of a consortium. If you are putting a requirement together, we publish a checklist of the twelve areas a workable EDMS requirement covers.

A Basic Deployment typically goes live in four to six weeks. A Standard Deployment with workflow automation typically runs eight to fourteen weeks. A Premium Deployment with AI processing, records management and integrations typically runs three to six months. The largest variable by far is digitisation of existing paper records, which runs in parallel and is sized from a sample survey rather than estimated.

Yes. Backfile conversion covers preparation, scanning, quality assurance, OCR, indexing against your file plan and re-boxing or secure disposal of the physical originals. We survey a representative sample first so the volume, condition and indexing effort are known before a price is quoted. Digitisation is priced per volume and runs alongside the system deployment rather than delaying it.

Every package includes role-based training for end users, records officers and administrators, delivered on site or online, plus the configuration workbook, standard operating procedures and user guides as your own documentation. Premium Deployment adds a train-the-trainer programme so your champions can onboard staff after go-live, and a change management workstream through the first quarter. Support after warranty is tiered, with defined response and resolution targets and a named account contact.

They stay exactly where they are. The repository sits in your own Microsoft tenant or your own data centre, under your own licences, and the documents, metadata and version history remain yours and remain accessible. The configuration, file plan and documentation are handed over to you as property, not licensed to you. There is no proprietary repository to extract data from and no export project to fund.

The platform provides the controls the Act requires an organisation to have: access limited by role and logged, encryption in transit and at rest, sensitivity labelling and data loss prevention over personal data, retention limits applied automatically so data is not held longer than necessary, and an audit trail that lets you demonstrate all of it. Compliance is a property of the organisation rather than the software, so implementation includes mapping your retention schedule and access model to your obligations — but the technical controls a Data Commissioner would ask about are in place and evidenced.

Wherever your policy requires. In a Microsoft 365 deployment, data resides in the Microsoft cloud region selected for your tenant. Where regulation or policy requires data to remain in country, the system can be deployed on SharePoint Server in your own data centre, or in a dedicated Azure region. Data residency is decided during the design phase and documented in the solution design, not assumed.

No. The AI capabilities run on Microsoft services within your own tenant boundary, and Microsoft commits that customer content processed by Microsoft 365 Copilot and its content-processing services is not used to train foundation models. Your documents remain subject to your own tenant permissions: the AI can only ever see what the requesting user is already entitled to see.

No. Records declared under a retention label cannot be edited or deleted by any user, including global administrators, until the retention period expires and a reviewed disposition takes place. The audit log is retained on its own independent schedule and is not editable from within the system. This separation is what allows the audit trail to be treated as evidence rather than as a convenience feature.