Summary

  • C & B Systemer A/S occupies a demanding position in Danish real-estate software: its products sit where property records, customer relationships, documents, signatures, public registers, websites and outside service providers meet. The company describes a history beginning in 1978, while registry evidence dates the establishment of the current A/S to 31 December 1984. That distinction matters because longevity can indicate accumulated domain knowledge, but it does not by itself prove that every current service has the same age, architecture or operating record. The public evidence supports a progression from products such as C&B BoligSystem, ErhvervsSystem and Classic toward the current RealEquity offering. It does not establish that these labels refer to one codebase, that all capabilities are equivalent, or that every customer has migrated.
  • RealEquity is presented by C&B as a broad workflow environment for brokers, with case and customer management, buyer registers, documents, communications, signing, portals and partner connections. Those are product capabilities. Reliability evidence is narrower: published support exclusions, a short-lived integration context, controlled data classifications and documented provider-switch procedures reveal where failures and handoff problems can occur, but no public service-level record establishes annual availability, recovery time, security effectiveness or error rates. Third-party material confirms several real uses, including signing from a broker workflow, publication of C&B-held property data to a separately built website, and named use of C&B Boligsystem. It does not provide audited gains in time, conversion, staffing, revenue or return on investment.
  • The practical question, therefore, is not whether C&B has a long feature list. It is whether a brokerage can supervise the state of each property case, detect exceptions across connected services, maintain templates and classifications, and preserve continuity when systems or suppliers change. That assessment has to include the people, agreements, reconciliations and migration work around the software, not just the functions displayed inside it.

Company directory: C & B Systemer A/S [S01]

A long company history with two dates that should not be merged

C&B's own history page says the business began in 1978 and describes an evolution from early real-estate systems through customer relationship management, electronic document handling and web-related capabilities. That is useful evidence of the company's account of its operating history. It is not the same thing as a legal incorporation record. A Danish company-data record identifies C & B SYSTEMER A/S, CVR 87844811, as an aktieselskab and gives 31 December 1984 as its establishment date. The same record places the company in Taastrup and classifies its activity under computer programming. The responsible formulation is consequently that C&B traces its business history to 1978, while the registered A/S dates from 1984. [S15]

The difference is more than a footnote. In enterprise software, a long trading history can be invoked as shorthand for product maturity. Yet a company can change ownership, product generations, delivery models, suppliers and technical boundaries over time. C&B's company account says VIA equity made a majority investment in 2018. A filed annual-report copy identifies C&B TopCo ApS as the parent and ultimate owner for the period covered by that report. These records permit a dated description of ownership context; they do not justify a current percentage for VIA equity without a fresh, exact ownership record. [S02]

The filed report also helps define the business more precisely. Management describes RealEquity as a customer relationship and case-management solution and discusses three user environments: Mæglerunivers for brokerage work, Kundeunivers for customers and Partnerunivers for connected parties. It also describes an application programming interface strategy. Because the management review is company-authored and belongs to a historical reporting period, it is evidence of strategy and product framing, not an independent audit of present-day functionality or service quality. Still, it shows that C&B has framed the product around multiple entity groups rather than a single back-office database. [S14]

That entity model explains both the attraction and the operating risk. A property case may involve a broker, seller, buyer, photographer, portal, signing provider, public-data service, financing or settlement counterpart, and website. A system that coordinates those parties can reduce duplicate entry and provide a common case view. At the same time, every boundary creates a place where identifiers, permissions, document versions or status signals may diverge. C&B's history is relevant because it suggests experience with the domain. It cannot substitute for current evidence about how those boundaries are monitored.

The public BTW directory entry confirms the canonical company name and directory slug. It is useful for identity and navigation, but its descriptive summary is not independent market-position evidence. The directory does not prove market share, customer count or the scope of any particular deployment.

A product family, not a timeless single system

The available material contains several overlapping labels. Older or historical names include C&B BoligSystem, C&B ErhvervsSystem, C&B BoligrådgivningSystem and C&B Classic. Current public material uses C&B Systemet and RealEquity, while also naming Mæglerunivers, Kundeunivers and Partnerunivers. It would be convenient to describe all of these as successive screens over one continuous platform, but the evidence does not support that conclusion. There is no public basis here for asserting one shared codebase, complete feature parity, identical hosting arrangements or a universal migration date.

C&B's page for the C&B System describes a domain-specific combination of case handling and customer management. It lists an electronic document-handling function, a buyer register, customer relationship management, a calendar and process control, along with portal, Outlook and outside-data connections. These descriptions illuminate what the company intends the system to help users do. They do not tell us which legacy and current packages contain identical implementations, how often each component changes, or which customers use each one. [S03]

The RealEquity solution page presents a current platform that spans residential, commercial, agricultural and advisory case types. It describes Mæglerunivers as the professional working environment and Kundeunivers as a customer-facing space, while partner connections cover such functions as signing, images, portals and buyer-related work. The RealEquity commercial FAQ adds responsive access, customer relationship functions, calendars, notifications, files, communications, business-intelligence features, signing and partner participation. Those pages support the existence of a broad designed scope. They do not prove that every function is included in every contract or equally mature. [S04] [S07]

As checked on 25 July 2026, the license-package page distinguished Basic and Pro packages, presented some functions, websites and document-template services through package or add-on boundaries, and indicated that parts of the commercial model involved transaction- or case-related fees. Prices and package definitions can change, so a buyer should date the quotation it relies on and attach the relevant package schedule to its decision record. A product demonstration that crosses several packages is not sufficient evidence that one contracted package includes all demonstrated functions. [S08]

This packaging has a direct operational consequence. Supervisors need to know whether a missing function is a defect, a configuration choice, an entitlement boundary or a separate service that has not been purchased. The response paths differ. A software defect may require vendor support; a configuration problem may belong to a local administrator; an entitlement issue may require a contract change; and an unavailable partner service may require escalation outside C&B. Treating all four as "the system is down" obscures ownership and delays recovery.

The product-generation boundary also affects training and documentation. A procedure written for BoligSystem or Classic cannot automatically be assumed to match RealEquity. Field names, process steps, document locations and connected services may differ even when the business objective is the same. Conversely, the continued appearance of a legacy label in a customer's public material does not establish that the customer rejected or failed to complete a later migration. It confirms only the named relationship in the context and date of that page.

For an evaluator, the useful unit of analysis is therefore not "C&B" in the abstract. It is a specific product generation, package, case type, user group and set of contracted connections. The evaluation should identify which functions are native to the purchased environment, which are supplied by partners, which are optional, and which remain in a legacy workflow during transition. Without that inventory, comparisons of cost or reliability combine unlike things.

Supervision begins with state, responsibility and evidence

Real-estate work is a sequence of decisions around a changing case. A broker records a property and its parties, gathers documents, communicates with customers, prepares marketing, handles interest, arranges signatures and coordinates completion. C&B's product pages describe tools that can place many of those steps in one working environment. That can improve visibility, but only if the brokerage defines what each status means and who is responsible for moving it.

The buyer register is a good example. C&B presents CRM and buyer-register functions as part of the system scope. A register can hold customer preferences and connect prospective buyers with relevant properties. The capability alone does not establish data quality. Supervisors still need rules for duplicate people, stale preferences, consent, incomplete contact details and ownership of follow-up. A matching result is useful only when the underlying property and customer classifications are current and when staff understand whether the result is advisory or decisive.

Process control and calendars similarly need an operating model. C&B describes process support, notifications and calendar functions, but no public material in the reviewed set quantifies completion accuracy or guarantees that every outside event creates a timely signal. A brokerage should specify which milestones are mandatory, which can be overridden, which require a second reviewer and how overdue items are escalated. It should also determine whether an action is considered complete when a staff member starts it, when an outside provider accepts it, or when the final artefact returns to the case.

That distinction matters for digital signing. Sending a document, receiving it at the signing provider and obtaining all required signatures are three different states. A partner case from esignatur describes initiating signing from the broker's existing C&B workflow, seeing document status and sending reminders. This is useful evidence that an integrated signing process was used. It does not prove that every signing request succeeds, that identity checks never fail, or that status information cannot be delayed. [S11]

Supervision should focus on state transitions that can be verified. For a document, those might include prepared, approved for dispatch, delivered to the signing service, opened, partly signed, fully signed, rejected, expired and returned to the case. The exact available labels are not established by the reviewed evidence and should be confirmed in the contracted product. The general control requirement is clear: staff must distinguish progress inside C&B from completion at a connected service.

Documents create another supervision challenge. The company says electronic document handling can support sharing and publication, and its current materials describe customer access to files and communications. A document may have a case-facing copy, a customer-visible copy and a copy sent to a partner. A responsible procedure needs to identify the authoritative version, govern replacement after correction, and record whether a withdrawn version remains accessible elsewhere. The presence of a document function does not answer those questions automatically.

Supervisors also need a practical exception queue. Cases with missing public data, failed signing, rejected files, incomplete portal publication or unresolved customer messages should not disappear among normal work. The available pages do not document a complete exception-management design, so it would be improper to claim one. This is an area for direct demonstration and contract review: which exceptions are visible, who can filter them, what notifications persist, and what evidence remains after resolution?

The quality of supervision finally depends on permissions. The public sources describe different user environments but do not provide a complete role-and-permission model. A buyer should ask who may create or alter parties, property facts, pricing, documents, templates and connection settings. It should also ask what review trail is available for sensitive changes. These are questions raised by the breadth of the workflow, not assertions that a particular control is present or absent.

Integration is a chain of contracts, classifications and timing limits

C&B presents connectivity as a central part of its offer. As checked on 25 July 2026, the system-package page said the environment had more than 90 integrations and named functions such as data and document exchange through Mægler Online, CPR validation and MitID signing. Because this is a first-party count, it should be attributed to C&B and not presented as an independently audited inventory. The more important issue is what "integration" means in each case: a live data exchange, a redirect, a file transfer, a manually triggered request or a commercial referral can impose very different operating demands. [S05]

The data-exchange page provides a more concrete view. It lists lead intake, photographer and image imports, BBR and land-register retrieval, reference-property data, rates and advertising-related connections. This shows how widely a brokerage workflow can depend on outside information. It does not publish error rates, data-freshness guarantees, reconciliation procedures or response times. Each connected flow therefore needs its own acceptance and exception rules. [S06]

Consider a property image. A photographer may produce files, a connection may import them into the case, staff may select and order them, and one or more portals or a website may publish them. A file can arrive but be attached to the wrong property; a caption can be outdated; one channel can retain an older image; or a format can be accepted in one destination and rejected in another. These are plausible control questions inherent in a multi-step exchange, not documented incidents at C&B. The buyer's task is to determine what checks the actual workflow provides and what must be done manually.

The public RealEquity developer forum supplies one unusually specific technical boundary. Its external-link documentation explains that extensions can be linked from the RealEquity interface and can retrieve context for a short period. The documented lookup lifetime is one minute. The returned context can include an actor, a resource group and, where relevant, a case. This supports a controlled handoff from RealEquity to an outside service, but it also creates a timing and error-handling obligation. [S09]

If a user opens a link and the outside service waits too long before retrieving the context, the lookup may no longer be available. The documentation establishes the time boundary; it does not state how every extension behaves when the period expires. A partner must decide whether to request a new context, show a clear retry path or stop the operation. The brokerage should test this behavior in its own accepted configuration and make sure staff can recover without accidentally creating a second request or using the wrong case.

Context transfer also raises identity and authorization questions. The documented shape can tell an extension about an actor and a case, but the reviewed page does not amount to a complete security assessment. A buyer should establish which party authorizes the extension, how access is withdrawn, what information is transferred, and how the outside service records its own activity. None of those questions can be answered merely by noting that an external link exists.

RealEquity's public taxonomy documentation reveals another integration layer: shared classifications. It publishes structured vocabularies for property and case concepts, branch organization and workflow-related values. Controlled enumerations are valuable because they reduce ambiguity between systems. They also require change management. A partner needs to know how it handles an unfamiliar value, a retired value or a classification that has different local meaning. [S10]

This is where integration maintenance becomes less visible but more important. A connection can continue responding technically while producing incomplete business results because one side has not recognized a new classification. Availability alone would miss that failure. Reconciliation should therefore check not only whether messages moved, but whether records were accepted, mapped and represented as intended. The public documentation establishes that classifications exist; it does not document the completeness of every partner's mapping.

Commercial boundaries matter as well. C&B's SaaS FAQ says API partner arrangements require written agreement. That means connectivity is not only a technical capability. It may depend on a contract defining access, responsibility, support and perhaps commercial terms. A brokerage considering a niche connection should verify that the relationship is covered and identify which organization supports the full path. The fact that an interface is documented does not establish that any party may use it without agreement.

The Dotpeople implementation provides third-party evidence of a connection in use. In its case description, Dotpeople explains that case and image information from C&B fed a separately developed Umbraco website. The website retained custom presentation, search and filtering, while the arrangement pursued a single-source administration model for property data. This is a meaningful example because it separates the system of record from the public presentation layer. [S13]

It also shows why outcome claims must remain limited. The case demonstrates that C&B-held data and images were used by another website. It does not provide a measured reduction in errors or administration time. Nor does it establish that every field, image or update appeared without delay. The custom website and its search logic remain distinct from C&B, so diagnosis has to distinguish a data problem at the origin, a transfer problem and a presentation problem at the destination.

The correct mental model is a chain of responsibilities. C&B may hold or expose a case state; a partner may transform it; a third service may complete an action; and another channel may present the result. A reliable operating process assigns an owner and a recovery route at each step. No single vendor's feature list can prove the reliability of the entire chain.

Documents and signatures expose the difference between capability and completion

Document work is where software convenience meets legal and operational consequence. C&B's product materials describe electronic document handling, customer document access, templates, communication and signing. These functions can bring related work into the case environment. They do not eliminate the need to manage document origin, version, approval and final status.

The esignatur case says signing could be initiated in the existing C&B workflow and that users could see status and issue reminders. The partner also used promotional language about time and conversion and included a historical statement about customer coverage. Those statements lack an independently measured baseline in the reviewed material and should not be converted into audited results. The defensible conclusion is narrower: a signing partner described an integrated C&B workflow with status visibility and reminders.

A later Scrive announcement documents a 2024 strategic partnership around signing and identity and states an intention for a renewed solution in January 2025. An announcement of planned delivery is not evidence that the planned service was completed on time, adopted by customers or proven reliable. It does, however, demonstrate that signing and identity functions depend on an outside specialist and that the partner arrangement can change. [S12]

That change has maintenance implications. Brokerages need to know which provider handles each document flow during a transition, whether old requests remain accessible, how templates and identity steps change, and where historical evidence can be retrieved. The reviewed material does not answer those questions. They belong in transition planning and acceptance work. The important analytical point is that an integrated button can conceal a separate service relationship with its own release schedule and support path.

Exception handling should cover partial completion. A document can require several signers; one may complete the step while another rejects, times out or cannot pass an identity check. A reminder may be appropriate in one case and harmful in another if the underlying document has been withdrawn. The public evidence does not enumerate C&B's handling of every scenario. An evaluator should require a demonstration of cancellation, replacement, resending, partial status, expiry and retrieval of the completed document.

Customer access adds another boundary. Kundeunivers is presented as a space for customer interaction and files. The brokerage should establish when a document becomes visible, whether visibility can be revoked, how an updated version is distinguished, and what customers see when a related outside service is unavailable. Again, these are control questions generated by the documented scope. They are not allegations of defects.

Document-template economics also belong in the total operating picture. The license material presents template-related services through package or add-on boundaries. Templates can reduce repetitive drafting, but they also require legal review, field mapping, version control and retirement of obsolete forms. A quoted license price does not capture the internal work needed to maintain the content. Nor does a template's presence prove that every field is correct for every case type.

What the public record can and cannot say about reliability

Reliability is often inferred from breadth, age or customer references. None is a substitute for direct operational evidence. C&B's long history and extensive product scope may be relevant to a procurement decision, but they do not establish annual availability, response time, recovery time, data-loss frequency, security effectiveness or defect rate. No such measures are supported by the reviewed sources.

The strongest direct reliability-related material is actually a set of boundaries. C&B's RealEquity terms identify circumstances outside ordinary support, including defective files or storage media, local equipment, communications links and third-party products unless separately covered. These exclusions do not prove unreliability. They clarify that end-to-end service depends on components C&B may not control and that responsibility can vary by agreement.

That distinction can determine how quickly a problem is resolved. If a user cannot retrieve an external record, the cause could lie in local connectivity, the outside service, credentials, a classification mismatch or the broker environment. The reviewed evidence does not permit assigning likely causes or percentages. It does show why support intake should capture the case, time, user action, affected connection and observed state rather than simply reporting that RealEquity failed.

The one-minute redirect-context lifetime is another concrete boundary. It establishes expected behavior at an interface but says nothing about overall availability. A failure after expiry may represent normal enforcement of the documented rule rather than an outage. Monitoring and user guidance should distinguish an expired context from a service that cannot be reached.

The public taxonomy page is evidence that integrations depend on shared structured values. It is not evidence that classifications never drift or that every partner implements them correctly. Operational reliability should include semantic checks: are required fields populated, are values understood at the destination, and do totals or item counts reconcile? A technical success response is not enough if the resulting business record is incomplete.

E-nettet's provider-switch guidance supplies independent evidence that continuity is a recognized concern in the Danish broker-system ecosystem. It lists C&B among supported providers, discusses an option for one month of overlap and addresses movement of open cases and data-processing agreements. This does not measure C&B's migration quality. It demonstrates that switching is a managed operational process rather than a simple account change. [S16]

Public reliability assessment is therefore constrained. A buyer needs private evidence appropriate to its risk: contractual service targets, maintenance windows, support escalation, continuity arrangements, incident communication, backup and restoration responsibilities, and accepted tests for its selected connections. This article cannot establish whether those materials exist or what they contain. It can only show why they are necessary.

Maintenance is continuous work across product, data and partners

Connected workflow software incurs maintenance in several layers. The visible layer is product change: new functions, interface updates, package changes and bug fixes. Less visible layers include document templates, user roles, branch structures, property classifications, partner agreements, website mappings and staff procedures. C&B's public scope touches all of them.

The structured taxonomies make classification maintenance especially important. A branch organization or property type used consistently across systems can support reliable exchange. A local workaround, free-text substitute or unmapped new value can undermine it. Brokerages should assign ownership for classification changes and verify downstream acceptance after updates. The reviewed documentation does not specify a universal notification or compatibility policy, so each connection's arrangements need confirmation.

User and partner access also changes over time. Staff join, leave or change roles; agencies reorganize; outside services are replaced; and customer cases close. The public evidence does not disclose a complete access-review process. A procurement and governance review should therefore ask how users and extensions are authorized, how access is withdrawn, and what historical activity remains visible. This is a standard consequence of a multi-party environment, not a statement about a known C&B deficiency.

Templates and communications require content maintenance. A file, email, SMS or notification function can deliver the wrong result if its wording, recipient rule or case field is outdated. C&B describes the capability to handle these materials, but not the brokerage's internal approval process. Legal and operational owners should agree who may publish template changes, how they are tested against case types and how older versions are retained where required.

Commercial maintenance should not be ignored. The license page distinguishes packages and add-ons, and the FAQ describes partner-agreement boundaries. A new requirement may therefore involve more than configuration; it may add a service, fee or contract. Total cost analysis should include recurring license and case-related charges, partner fees where applicable, template work, integration upkeep, staff training and transition support. The sources do not provide enough evidence to calculate a representative total.

Maintenance planning also needs a product-generation view. A brokerage operating Classic or another older label alongside RealEquity may have different procedures and connections for similar work. The evidence does not establish how many customers are in that position or which functions differ. A buyer or migrating customer should create its own inventory and avoid assuming that documentation for one generation applies to the other.

Migration cost is measured in continuity, not only data volume

Migration is where the distinction between a product capability and an operating outcome becomes most visible. Moving property and customer records is only part of the job. Open cases may contain parties, documents, communications, appointments, signing states, images, portal publication, buyer matches and partner references. A technically successful transfer can still leave staff without the context needed to continue work.

E-nettet's provider-switch page is valuable because it treats switching as a defined process. It names C&B among broker-system providers, allows for a one-month overlap option and discusses open-case movement and data-processing arrangements. The overlap option indicates that continuity may require both systems to coexist temporarily. It should not be read as a mandatory or sufficient period for every migration. The appropriate duration depends on the actual process, agreement and case inventory.

Overlap has direct costs. Users may need access to two systems, training may cover both, and procedures must say where new work belongs. Data can diverge if the same record is changed in both places. Connections to portals, websites, signing providers and public services may switch on different dates. The reviewed evidence does not specify C&B's exact migration method or fee structure, so those details must be established for the particular project.

Open cases are more difficult than closed records because they contain pending obligations. A document may be awaiting signatures, a customer may be reviewing files, an image set may be scheduled for publication, or an outside request may not yet have returned. A migration plan should identify such states, decide whether they are transferred or completed in the old environment, and define evidence of completion. The sources establish the importance of open-case movement but do not prove automated preservation of every status.

The transition from C&B Classic or older BoligSystem and ErhvervsSystem labels to RealEquity deserves the same care. Public material supports a product-line evolution, but it does not prove universal completion, one-to-one field correspondence or equal behavior. Migration assessment should compare the actual legacy configuration with the contracted RealEquity package. Generic statements about "moving to C&B" are too imprecise when both the starting and destination environments may contain optional or customized elements.

Website integration adds another migration surface. The Dotpeople case demonstrates a model in which C&B supplies case and image data while an Umbraco site owns custom presentation, search and filtering. If the underlying broker system changes, the website mapping and publication behavior may need adjustment even if the public design remains unchanged. Acceptance should verify not just that records arrive, but that search, filters, images and withdrawn properties behave correctly.

Signing and identity transitions add a further dependency. Scrive's 2024 announcement described a planned renewed solution for January 2025, but the announcement is not proof of completion. Where a partner changes, migration planning should cover outstanding requests, historical evidence, templates, user authorization and fallback procedures. The same principle applies to any outside connection whose contract or interface changes during a broker-system migration.

Training is a material migration cost even when the new environment offers familiar concepts. Staff may recognize a buyer register, calendar or document area while still encountering different status definitions and exception paths. Training should include abnormal scenarios, not only the ideal sequence. The public materials do not quantify the necessary effort, so no defensible number can be given here.

Data validation is another cost that license comparisons can miss. Counts of properties, customers or files can be reconciled, but counts alone do not prove correct relationships. Samples should cover different case types, open and closed states, multi-party documents, images, buyer criteria and connected outputs. The particular acceptance method belongs to the migration parties; this article does not claim that C&B supplies or omits any named procedure.

Exit planning should begin before migration into a new system. A brokerage should understand how it can retrieve case records, documents and relevant history, what formats are available, which partner data sits elsewhere, and how long access remains after termination. E-nettet's switching guidance and data-processing context make the issue concrete, but they do not settle each commercial agreement. Exit cost is part of lifecycle cost even when no switch is planned.

Evidence of use is real, while evidence of customer gains is limited

There is credible third-party evidence that C&B systems participate in real operating workflows. The esignatur case describes signing inside an existing broker process. The Dotpeople case describes property case and image data feeding a customer website. E-nettet lists C&B as a system provider in a switching process. BoligOne names C&B Boligsystem in its operating stack alongside marketing and lead-generation tools. [S17]

These examples matter because they go beyond C&B's own feature pages. They show that outside organizations have built around, connected to or publicly identified a C&B system. They remain individual examples with different dates and contexts. They do not establish representative satisfaction, current market share, average reliability or a standard financial outcome.

The BoligOne reference is especially bounded. It confirms named use of C&B Boligsystem and places that system beside other operational tools. It does not say which version, package or features are in use. It offers no performance data. The correct use of the reference is to demonstrate a customer-side system relationship, not to infer endorsement of every C&B product.

Likewise, the Dotpeople project shows a single-source administration objective and a working division between broker data and a custom website. It does not quantify whether administration decreased or data accuracy improved. Those may be reasonable goals, but goals and measured outcomes are different. The evidence supports the architecture of responsibility at a high level: C&B data on one side and custom presentation and search on the other.

Partner marketing requires explicit attribution. Esignatur's language about benefits and its historical coverage statement belong to the partner case, not to an audited comparative study. Scrive's partnership description establishes direction and dependency, not adoption. C&B's own statements about integration breadth and product efficiency likewise remain first-party descriptions. None should be converted into numerical gains.

An evidence-based customer assessment would need a defined sample, baseline, time period and method. It would distinguish software effects from process redesign, training and staffing. No such study appears in the accepted materials. Accordingly, this article does not state a time saving, conversion increase, revenue gain, staffing reduction, error reduction or return on investment.

Failure modes that a responsible evaluation should document

The public record supports identification of failure surfaces, but not claims that these failures have occurred at a particular frequency. The first surface is stale or incorrect case state. A case system can contain the expected fields while staff disagree about what a status means or fail to update it. Process controls, calendars and notifications can help, but the company pages do not establish completeness or accuracy. Governance needs definitions, ownership and escalation.

The second surface is document divergence. A case, customer area, signing provider and outside recipient can hold related copies. Correction after dispatch can create uncertainty about which version is authoritative. C&B describes document handling and customer access, while partner material describes signing status. The accepted evidence does not document every replacement and withdrawal behavior. Those paths require direct verification.

The third surface is delayed or expired integration context. RealEquity's developer documentation specifies a one-minute lifetime for context retrieval from an external link. A slow or interrupted handoff may therefore require a new request. The evidence does not say how every partner handles expiry. A clear retry path and duplicate-prevention rule should be demonstrated.

The fourth surface is classification mismatch. RealEquity publishes structured taxonomies, and connected systems need to interpret them. A new, changed or locally misunderstood value can produce an incomplete result even when transport succeeds. Reconciliation should include business meaning, not merely message delivery. No public evidence in the reviewed set quantifies mapping errors or describes universal compatibility controls.

The fifth surface is outside-service dependency. Signing, identity, public-register retrieval, portals, websites, photography and communications can involve separate operators. C&B's support exclusions explicitly recognize local, communications and third-party boundaries. Failure diagnosis must identify the responsible segment, and continuity plans should say what users do when a connection is unavailable. The sources do not prove that C&B operates every dependency itself; they indicate the opposite in several partner relationships.

The sixth surface is package or agreement mismatch. A function shown publicly may belong to Pro, an add-on, a transaction fee or a written partner agreement. Users can interpret unavailable functionality as a defect when it is not part of the purchased scope. Procurement records, configuration inventories and support procedures should align.

The seventh surface is partial migration. Open cases, pending signatures, websites and partner connections may transition at different times. E-nettet documents overlap and open-case concerns, while the legacy-to-RealEquity evidence does not show universal completion. A migration that transfers master records but loses pending state would not meet operational continuity needs. This is a risk to test for, not a documented outcome attributed to C&B.

The eighth surface is incomplete reliability evidence. Incident frequency, duration and root cause require accessible, authoritative service records. A buyer should obtain those records before forming an availability estimate.

The ninth surface is customer evidence that is too small or promotional. A few reviews, a partner case or a vendor response cannot represent an entire customer base. The accepted material offers useful examples but no statistically defensible satisfaction measure. Procurement teams should identify the customer segment, product generation and connection set behind any reference.

The tenth surface is mistaken product equivalence. Names such as BoligSystem, Classic, C&B Systemet and RealEquity appear across different materials. Treating them as interchangeable can corrupt requirements, pricing and migration plans. Every statement about functionality should be tied to a named generation and package wherever possible.

Several major evidence gaps remain. There is no accepted public basis here for an availability percentage, recovery-time measure, security assessment, data-residency statement, latency measure, error rate, migration success rate or complete partner inventory. There is no proof that every legacy customer has moved to RealEquity. There is no independently audited current market share or current VIA equity percentage. There is no measured customer return.

These gaps do not prove negative performance. They set the limit of what can be responsibly concluded from public material. Private procurement evidence may answer some of them, but it should be dated, scoped to the purchased service and checked against the actual connection set.

A practical evaluation framework

A brokerage evaluating C&B can organize its work around five questions. First, what is the exact service boundary? The answer should name the product generation, package, case types, add-ons and outside connections. It should distinguish RealEquity from any retained Classic or older workflow and identify where customer and partner environments begin.

Second, how is work supervised? The evaluation should trace a property case from entry through documents, customer access, publication and signing. For each material transition, it should identify the responsible role, visible status, exception signal, escalation route and completion evidence. Demonstrations should include abnormal cases such as expiry, rejection, missing data and replacement of a document.

Third, how are integrations governed? Each connection should have an owner, agreement, data scope and support path. The evaluator should verify context expiry behavior, classification handling and reconciliation of accepted records. A list of integrations is a starting inventory, not proof of end-to-end operation.

Fourth, what must be maintained? The answer should include roles, templates, branch and property classifications, website mappings, partner credentials, package changes, staff procedures and training. Maintenance responsibility may sit with C&B, the brokerage or another provider. The contract and operating handbook should say which.

Fifth, what would change or exit cost? The brokerage should inventory open cases, documents, pending signatures, images, websites and outside references. It should establish export and overlap arrangements, acceptance criteria, access after termination and responsibility for historical evidence. The one-month overlap option described by E-nettet is a useful example of continuity planning, not a universal estimate.

This framework does not produce a score from the public material alone. It converts broad product descriptions into verifiable operational questions. That is the appropriate response to an environment where capability evidence is strong, reliability evidence is bounded and customer outcome evidence is mostly attributed examples.

Conclusion

C & B Systemer A/S can be described with confidence as a Danish software company with a business history it traces to 1978 and a registered A/S dating from 1984. Its public materials present a domain-specific workflow scope spanning cases, customers, buyer registers, documents, communications, signing, public information and partner connections. Public technical documentation confirms a short-lived context mechanism and structured integration vocabularies, while independent ecosystem material shows signing, website-data, customer-use and provider-switch workflows around C&B systems.

What cannot be responsibly claimed is equally important. The evidence does not establish that all historic and current product labels share one codebase or that every customer has migrated to RealEquity. It does not establish an SLA, availability rate, security effectiveness, error rate, migration success rate, current audited market share or measured customer return. Partner plans and marketing statements must remain attributed and dated.

C&B is therefore best evaluated as an operating system for relationships and handoffs, not merely as a collection of screens. Its value depends on whether a brokerage can supervise case state, maintain documents and classifications, manage outside dependencies, resolve exceptions and preserve continuity through change. Those capabilities may be supported by the product, but the outcome is created jointly by software, contracts, connected services and disciplined operating practice. Public evidence can define the questions and some boundaries. The final answer requires service-specific, package-specific and connection-specific proof.

Sources